Primitive Queue<any T> considerations

Vitaly Davidovich vitalyd at
Thu Nov 19 00:01:30 UTC 2015

Right, by performance penalty I meant that I'd like to ask only for
atomicity and not also ordering.  If the T is <= machine word, I'd like it
to act just like if I hadn't requested atomicity.  In other words, I don't
want fences here for ordering.

sent from my phone
On Nov 18, 2015 6:41 PM, "John Rose" <john.r.rose at> wrote:

> P.S. Meant to respond to this too:
> On Nov 18, 2015, at 12:38 PM, Vitaly Davidovich <vitalyd at> 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

More information about the valhalla-dev mailing list