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

[John Rose]

On Jan 29, 2018, at 7:31 PM, Frederic Parain <frederic.parain at oracle.com> wrote:
> During a brainstorming session with Karen this morning, we realized
> that case 2-A (ACC_FLAT flag set for an object class) should be in
> fact treated as an error, instead of just ignoring the flag.

I agree, this is a cleaner option, better than saying "oops, not flat
after all".  Using Remi's notation, the choice is between:
  ACC_NON_NULLABLE_AND_ERROR_IF_OBJECT_TYPE
or:
  ACC_NON_NULLABLE_UNLESS_OBJECT_TYPE

Also, forbidding this configuration leaves open, as a future option,
the ability of a classfile to specify non-nullable reference fields.
That is potentially useful, depending on the future fortunes of
null (that billion-dollar mistake).  I'm sure we can figure out some
way to construct such fields without requiring them to contain
a null initial value.

> These two modifications makes the semantic mucho simpler and
> cleaner with only two cases: one where null is always valid, and
> one where null is never valid.

Bingo.  This feels right.

> So here’s a re-write of the semantic:
> 
> Fields have a new access flag called ACC_NON_NULLABLE.
> 
> The type of a field with the ACC_NON_NULLABLE flag set must
> be a value class type, otherwise an ICCE is thrown.
> 
> 1 - If a field is declared without the ACC_NON_NULLABLE flag set:
>     - this field is initialized with the null reference
>     - it is valid to write null to this field
>     - note: JVMs are unlikely to flatten such field

(…although JVMs could flatten, if they were willing to find an alternative
flat representation for null.  I can think of several options, not all of which
are crazy.  So I think "unlikely" is too strong a word.  Suggest
s/unlikely/not required/.)

> 
> 2 - If a field is declared with the ACC_NON_NULLABLE flag set:
>     - this field is initialized with the default value of this field’s value class
>     - writing null to this field causes a NPE
>     - JVMs are encouraged to flatten such field
> 
> This semantic makes much more sense because being non-nullable
> is a property of the container more than a property of the field’s type.

Yes, exactly.

So we have a four-way matrix of {nullable, non-nullable} x {object type,
value value}.

Only one element of the matrix is erroneous, and could in fact be assigned
a meaning in the future.

nullable object:  today's semantics
non-nullable object:  illegal (reserved for possible future use)
nullable value: JVM promises to record nulls (compatibility with past usage)
non-nullable value:  works like an int!

Is there anything to say about interface types, or Object (the honorary interface)
which differs from plain object references?  Both interfaces and Object can
be assigned value instances as well as object instances.  A JVM could potentially
flatten field values *conditionally* depending on the dynamic type of the field's
contents.  (Insert more crazy ideas here.)  Probably the best answer here is to
control the variance of the type so it is determined when the field is created,
by capturing it as a template parameter, part of the fixed type of the instance.

The short answer is that, in our system, interfaces are inherently nullable.
Maybe we can create non-nullable interfaces in the future.

Speaking of templates and nullability:  The distinction of List<T> vs. List<any T>
includes the observation that in List<T> the element type is always nullable,
while in List<any T> the element type is nullable only if T is an object or interface
type.  That's ACC_NON_NULLABLE_UNLESS_OBJECT_TYPE, which is
rather unwelcome in the current conversation.

I guess a template class mechanism which can support List<any T> will
have to have such a degree of freedom.  The nullability of a template field
of type T will have to be a function of whether the T parameter is a value
type or not.  That's a requirement on the templating mechanism, but it
doesn't necessarily affect today's choice about field flatness.

It's funny how setting out to design user-programmable primitive types
forces us to solve problems with null.  I usually think that the downside
of null is having to deal with unexpected NPE's, but another downside
is that null gets in the way of flattening.

— John