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

Srikanth srikanth.adayapalam at
Tue Feb 13 09:58:07 UTC 2018

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

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 

(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: (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)


More information about the valhalla-dev mailing list