Primitive Queue<any T> considerations
vitalyd at gmail.com
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 oracle.com> wrote:
> P.S. Meant to respond to this too:
> On Nov 18, 2015, at 12:38 PM, Vitaly Davidovich <vitalyd at gmail.com> wrote:
> 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.,
> 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