JVMS draft for L-world value types with support for nullability

[Frederic Parain]

Hi Paul,

> On Jan 31, 2018, at 15:50, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> 
> Hi Fred,
> 
> Some basic questions, which might be because the specification is transitioning from value-based to value classes.
> 
> 
>> The ACC_ENUM flag indicates that this class or its superclass is declared as an enumerated type. A class file must not have both ACC_ENUM and ACC_VALUE_TYPE flags set.
> 
> 
> Why can’t enum classes be values classes, where enum values are actual values? I think the answer may be below.

First of all, there’s a backward compatibility issue with old enums. They have been defined with full identity,
which is incompatible with being a value type.
There’s also an issue with the super-type. The super-type of all enums is the abstract class java.lang.Enum,
but the super-type of a value class must be java.lang.Object.
One advantage of values types is that the JVM can flattened them, it is possible because of two properties:
being identity-less and having a default value. Without a default value, the JVM cannot initialized a non-nullable
field, so flattened cannot be performed,

> 
> 
>> The ACC_NON_NULLABLE flag indicates that this field must never store the null reference. The field signature must be the signature of a class. The class specified in the field’s signature is loaded during the loading phase of the class declaring this field. The class of the field must be a value class. This field must be initialized with the default value of this value class.
> 
> 
> I suppose in theory this attribute could be applied to a non-value class?

No as it is define today, because of the lack of non-null default value for non-value class, which makes the initialization
of such field impossible for the JVM.

A future project might be to enable ACC_NON_NULLABLE for non-value class, but
it would require a much complex initialization scheme, probably involving indy or condy.
This is way beyond the scope of this draft.

> 
> 
>> A field must not have both ACC_STATIC and ACC_NON_NULLABLE flags set. 
> 
> This would rule out the static fields of a enum class, although in this case i would presume an enum class is such that after static initializer block all static fields would be assigned since they are also marked final. 
> 
> So, if static fields can be final then why not non-nullable?

This is an open question.

The rational of the current choice is to avoid some circularity errors with some
common construct for static fields.

The ACC_NON_NULLABLE flag is a marker for the JVM that indicates where flattening
is possible. The gain of flattening static fields is very small compared to the gains of
flattening of instance fields or array components. And the risk of circularity errors is high.
For instance, it is impossible to for a value class to have a static field with ACC_NON_NULLABLE
of its own type. Static fields are initialized during the preparation phase (JVMS 5.4.2),
which means for these fields  to store the default value of the class, but the class
has not been fully initialized yet, so it is still impossible to create such default values.
The problem exists also with indirect references to the current class (cycles).

So allowing ACC_NON_NULLABLE for static fields would require to write a new set
of restrictions in the language about when the flag can be used and and it cannot.
We saw theses constraints as a useless burden for the language (because the purpose
of the flag is to enable some implementation optimizations), so we proposed
to simply forbid them.

If the language team thinks there’s more value in allowing ACC_NON_NULLABLE, we
can revisit the current choice.

Fred


> 
> 
>> On Jan 31, 2018, at 11:38 AM, Frederic Parain <frederic.parain at oracle.com> wrote:
>> 
>> Here’s a draft of the JVMS proposing a way to implement the L-world value types,
>> with support for value-based classes migration to value classes (essentially, support
>> for nullability):
>> 
>> http://cr.openjdk.java.net/~fparain/L-world/L-World-JVMS-3.pdf
>> 
>> The assumptions and key properties are listed in Karen’s document:
>> 
>> http://cr.openjdk.java.net/~acorn/LWorldValueTypesjan31.pdf
>> 
>> 
>> Feedback and comments are welcome.
>> 
>> Fred
>> 
>