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

[Srikanth]

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

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 ?

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

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

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)

Thanks!
Srikanth