Moving from VVT to the L-world value types (LWVT)
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: <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
More information about the valhalla-dev