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

Srikanth srikanth.adayapalam at
Wed Feb 14 04:39:41 UTC 2018

All clarifications sound good. Thanks Fred.

Instead of a modifier to request flattenable fields, I have an almost 
working version in my workspace
that introduces and uses a new annotation java.lang.Flattenable 
(alongside, @Deprecated, @FunctionalInterface, @Override, @SafeVarargs, 
@SuppressWarnings ...)

Modifiers bring in issues around context sensitive keywords, annotations 
are cleaner IMO.

I will be pushing this to the branch soon. Let me know if there is a 
strong reason to prefer a modifier at the prototyping stage itself.


On Wednesday 14 February 2018 01:58 AM, Frederic Parain wrote:
>> On Feb 13, 2018, at 04:58, Srikanth <srikanth.adayapalam at> wrote:
>>> An updated version of the draft is now available here:
>>> 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:
>> (Allow updates to instance fields of value types via withfield by any method in the same nest)
>> (Should javac disallow null being cast into a value type ?)
>> (Add support for ACC_FLATTENABLE flag for fields.)
>> (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