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

[Frederic Parain]

> On Feb 13, 2018, at 04:58, Srikanth <srikanth.adayapalam at oracle.com> wrote:
> 
> 
>> An updated version of the draft is now available here:
>> http://cr.openjdk.java.net/~fparain/L-world/L-World-JVMS-4b.pdf
>> 
>> Thank you this very useful feedback,
>> 
>> Fred
> 
> Some more comments after reading L-World-JVMS-4b.pdf:
> 
> (1) "A field declared with the ACC_FLATTENABLE flag set must not have the type of its
> declaring class, nor refer indirectly to its declaring class through a chain of fields with
> the ACC_FLATTENABLE flag set."
> 
> (a) Does this signal an equivalent change in how javac handles cyclic value type membership checks ?
> for example we presently reject:
> 
> __ByValue final class X {
>     X x;
> }
> 
> with error: cyclic value type membership involving X.

Yes, this is one of the bug change in the draft. fields without the ACC_FLATTENABLE flag set
are handled as regular fields, even if their type is a value class type: no pre-loading, no cycle
detection.

The semantic and code we have developed during the VVT exploration now only applies to
fields with the ACC_FLATTENABLE flag set (this flag can only be applied to fields with a type
that is a value class type).

> 
> Given there is no source level annotation/modifier (as yet unspecified) to signal FLATTENABLE in the snippet above, should we accept this code ? OIOW, should javac's check for cyclic value type membership continue to be keyed off of the __ByValue modifier or the annotation/modifier for ACC_FLATTENABLE ?

We haven’t go through the details on how this would be exposed in the language, and what would be
the default. For exploration purposes, we’d like to have another modifier to tell javac to set the ACC_FLATTENABLE
flag on a given field.

> 
> (b) Not pertinent to javac, but still curious: so will the ACC_FLATTENABLE bit be the ultimate/sole determining factor for whether a field would be flattened or will there be other additional criteria ?
> 

The ACC_FLATTENABLE flag means this field has a value class type, and we would like it to be
flattened. The JVM will be free to decide to flatten this field or not based on its own criteria like the size
of the instance, the size if the container, if the field is a static or a non-static field, and in the future, may
be other modifier like one requesting atomic updates.
The decision of the JVM to flatten the field or not would not impact the semantic of the language.
A reference field without the ACC_FLATTENABLE flag set will be initialized to null.
A reference field with the ACC_FLATTENABLE flag set will be initialized with the default value of
the value class, even if the field has not been flattened.

> (2) withfield:
> 
> "The field must be final, it must be declared in the current value class, and the
> instruction must occur in a method of the current value class. Otherwise,
> an IllegalAccessError is thrown."
> 
> I think this needs a tweak - John is proposing any method in the same nest, not just the current value class ?

Correct, but the version of the JVMS I’ve used as a starting point to write this draft
doesn’t have the nestmate specification in it yet.

> 
> I have raised the following tickets against javac for the remaining work there:
> 
> https://bugs.openjdk.java.net/browse/JDK-8197792 (Allow updates to instance fields of value types via withfield by any method in the same nest)
> https://bugs.openjdk.java.net/browse/JDK-8197791 (Should javac disallow null being cast into a value type ?)
> https://bugs.openjdk.java.net/browse/JDK-8197799 (Add support for ACC_FLATTENABLE flag for fields.)
> https://bugs.openjdk.java.net/browse/JDK-8197830 (Javac's treatment of == and != involving at least one value operand.)
> 
> (The last one will likely be closed with no change for the reasons documented there)
> 

Thank you very much, this will be very helpful to keep track of these issues,

Regards,

Fred