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

[Srikanth]

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.

Thanks!
Srikanth

On Wednesday 14 February 2018 01:58 AM, Frederic Parain wrote:
>
>> 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
>
>