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

Frederic Parain frederic.parain at oracle.com
Tue Feb 13 20:28:39 UTC 2018

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 ACCFLATTENABLE 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 ACCFLATTENABLE 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 ACCFLATTENABLE ?

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 ACCFLATTENABLE 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 ACCFLATTENABLE 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

More information about the valhalla-dev mailing list