Thanks for this write up John - it covers the space really well.
Digging a little bit into the need for a pivot field by emphasizing
two points in your email:
> The simplest way to support null is just to do what
> we do today, and buffer on the heap, with the option
> of a null reference instead of a reference to a boxed value.
>
<snip>
> The next thing to do is inject a *pivot field* into the flattened
> layout of the primitive object. When this invisible field
> contains all zero bits, the flattened object encodes a null.
> All the other bits are either ignorable or must be zero,
> depending on what you are trying to do.
As we discussed on the last EG call, bucket 2 (nullable, non-tearable
values) are primarily flattenable today only up to the limit of what
the hardware can atomically load & store for us - basically a single
reference (aka 64 bits) on most modern machines.
The pivot field is only beneficial (required) for bucket 2 values that
can fit in 64bits as a way to avoid heap buffering. A pretty narrow -
though important due to use cases like Optional! - range of values.
Have I missed a use case or a way to extend this beyond what today's
hw will give us?
Assuming I haven't, it seems like the encoding schemes you proposed
for the VM cover this space well and it's unlikely that option 2
("language promises not to use the field") will provide much
additional benefit. Better to spend our translation complexity budget
elsewhere unless we have data showing a lot of bucket 2 values,
composed of multiple fields with no free bits with a size less than
64bits, are prevalent in our corpus of programs.
--Dan
