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

[Srikanth]

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: <null> 
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 ACC_FINAL 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