Primitive Queue<any T> considerations

[John Rose]

P.S. Meant to respond to this too:

On Nov 18, 2015, at 12:38 PM, Vitaly Davidovich <vitalyd at gmail.com> wrote:
> 
> [Brian]
>> Nullability is orthogonal to atomicity.  If he wants nullability, he wraps
>> his values with Optional<T>.  (For refs, Optional<T> will hopefully be the
>> same size as a ref, so it isn't a problem to do this across the board.)
>> For atomicity, you don't switch on size, you just ask for it.  If the
>> values are small, atomicity will be free or cheap anyway.
> 
> 
> Well, if there's going to be a way to request just atomicity (and not
> ordering as well), which will nop if size is atomic natively, then great.

I think value types will be a good way to signal a number of intentions
to the JVM, where today we use special types (WeakReference)
or annotations (@Contended).  An any-parameterized value type
W<T> which wraps another type T will need no header or padding,
and will often have no other storage besides the T value itself.
It will be able to express special storage semantics for the
wrapped T value (expressed as a variable of type W<T> or
an associated VarHandle<T> in some cases).  Special variable
handling conditions could include atomicity, contention, volatility,
dataflow control, finality, optionality, multiplicity, weak rooting, etc., etc.
The fun thing about this is that (potentially) we can mix and match
these features by stacking value types, without sacrificing flatness.

(Somebody is probably thinking, "wait, value types are final, so they
can't make state transitions!"  The answer is that the value as a whole
is mutable.  Remember, "codes like a class, works like an int", and an
int has no mutable subparts by can, as a whole, be mutated, unless
stored in a final variable.)

BTW, what would a weakReference<pair<P,Q>> look like?  Perhaps
it would clear itself only when *both* P and Q went unreachable.
That's a long-standing RFE for weak refs.  It appears that variable
attributes based on value-wrappers may be strictly more expressive,
in some cases, than the present options.

> Otherwise, I'd hate for there to be *any* performance penalty if the size
> is <= word size.

I don't anticipate any such penalty.  Value-based wrappers will be much
slimmer and lighter than object-based wrappers.

…Except for the per-value 64-bit lock word.  …Kidding.

— John