Consequences of null for flattenable representations

[Dan Heidinga]

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