Moving from VVT to the L-world value types (LWVT) (original) (raw)

Srikanth srikanth.adayapalam at oracle.com
Tue Feb 13 06:32:50 UTC 2018

On Tuesday 13 February 2018 12:42 AM, John Rose wrote:

On Feb 12, 2018, at 8:53 AM, Srikanth <srikanth.adayapalam at oracle.com> wrote:

Hi Frederic,

A couple of follow up questions below: On Monday 12 February 2018 10:02 PM, Frederic Parain wrote: [...] The current design allows null references for value types, as long as they are not stored in a container (field or array) declared as flattenable. This is a significant change from previous design. So, casting null to a value class type is now legal. OK. This does not call for any change to the specification of checkcast in JVMS ? (I don't know that it does - Just double checking) There might be an option here: Maybe we could get away with having checkcast throw NPE if the target class is a value type. After all, the checkcast instruction resolves its class operand. Remember that we must allow polluting nulls in fields which are not explicitly marked as flat, but only because of binary compatibility requirements. We do not allow polluting nulls to be stored into arrays, because arrays must resolve their element types before the first array is constructed. I think we could put checkcast into either of these two categories: Allowing polluting nulls for compatibility, or forbidding them (throwing NPE).

OK, I have raised https://bugs.openjdk.java.net/browse/JDK-8197791 to track this issue from javac side. ATM, javac rejects such casts with  error: incompatible types: cannot be converted to ...

I will work on it after the discussion settles down and there is clarity on the course of action.

[...]

_Thinking more about this, it might be time to drop ValueFactory and allow all methods from a value class to use withfield. I cannot remember the argument in favor of stricter rules for this bytecode. Problem in allowing all methods to use withfield is that it will make the final keyword meaningless as it is defined now. That's not right. Final means "you cannot perform putfield" (plus JMM effects). It says nothing about withfield. This is not just hair-splitting: withfield produces a new instance of the value. Final is only about preventing side effects to an existing (object) instance. It is one thing to say a specially privileged method that is really a factory and so works with nascent values is allowed to update instance fields that are marked final and that it really results in copy-on-write semantics. There is precedence for such - a constructor is privileged to set blank final fields. (indeed it must), quite another to open the floodgates. There are no floodgates here; there is a legitimate need for withfield to support field updater methods directly, instead of indirectly by reclassifying them as constructors, or refactoring them to call hidden constructors. I am not saying it cannot be done, but we need to redefine finality for fields of a value type in order to be able to do that. See above. It's not even a redefinition, just a refusal to carry the existing definition (no putfield outside of constructor) to a new place where it doesn't belong. OK, Agree with your points, it is a shift in thinking that can be taught and learnt and is part of value physics as you call it.

Bottom line: Allow vwithfield as a private operation to any method in the same nest. Require ACCFINAL on fields. Maybe relax some of these limits in the future.

— John OK, I have raised https://bugs.openjdk.java.net/browse/JDK-8197792 to get rid of the static value factory mechanism altogether and allow any method in the same nest to produce an updated value instance via withfield.

I will work on the latter now as I think there is strong consensus there already.

Thanks! Srikanth

More information about the valhalla-dev mailing list