Primitive Queue<any T> considerations

[John Rose]

On Nov 18, 2015, at 12:16 PM, Vitaly Davidovich <vitalyd at gmail.com> wrote:
> 
> Using David's example, say he wanted to have queue of nullable longs, which
> internally he'd store as Optional<long>.  But how does he specify in his
> generic class definition that when sizeof (Optional<T>) > word size that
> he'd like atomic access? This goes back to specialization selection, but
> has size constraint.

It doesn't need specialization.  It can be expressed with a use-site keyword
for atomicity, or (better) just for a suitable wrapper type.

class MyQ<T> {
   private optional<T>[] buf0;
   private atomic<T>[] buf1;
   private atomic<optional<T>>[] buf2;
   ...
}

An atomic<T> of a naturally atomic type T can be bitwise identical
to its underlying T.  For a larger T, the JVM will have to allocate
mutex resources, but it is not required to allocate a mutex per field,
so it is likely the resources will be amortizable (e.g., in the containing
object header, split lock side table, etc., etc.).