State of javac support for lworld-values.

[John Rose]

On Mar 26, 2018, at 5:13 PM, John Rose <john.r.rose at oracle.com> wrote:
> 
> I don't think the VM should ever allow a type T to be defined as a value type
> and then allow a heap variable of exact type T to be nulled. 

P.S. A couple more comments, FTR.

I'm primarily arguing here that flattenable heap variables won't be nullable,
i.e., that you'll never load a null from one.  The reason is that, for many value
types, and certainly for all primitives except booleans, there aren't enough bits
to represent the all the possible values, *plus* the one extra null value, without
making the data structure larger.  But that would work against a primary value
proposition, that if you use value types you'll get flatter, more compact values.

(Keeping things flat and coherent in a few cache lines is also a reason to work
hard on tearing control for volatiles and atomics, but that's a separate
conversation that can wait.  For now we can use a non-nullable internal
reference to the buffered value, if it's too big.)

Secondarily, one could ask the JVM to be lenient on stores to flattenable
heap variables, by converting on the fly from a null reference to the
default value of the stored flattenable type.  Thus you could seem to
store a null into a heap variable, though you could never load the null
back out.  I don't this this proposal would pay for itself.  Using the
"works like an int" heuristic, notice that we have lived without the
corresponding feature for ints for a long time:  If you unbox a null
Integer you don't get a default (zero) int, you get NPE.  Since
that behavior is convenient for the JVM, let's try to keep to it
for value types.