[jmm-dev] jdk9 APIs

[Aleksey Shipilev]

On 08/10/2015 09:22 PM, Doug Lea wrote:
> /**
>  * Stand-in for spec purposes of jdk9 java.lang.invoke.VarHandle
>  */
> abstract class NotReallyVarHandle<T> {
>     // CAS
> 
>     boolean compareAndSet(Object owner, T cmp, T val);
>     boolean compareAndSetAcquire(Object owner, T cmp, T val);
>     boolean compareAndSetRelease(Object owner, T cmp, T val);

Another, perhaps, "can of worms" question about CAS-es that was lurking
in my mind: which <T>-s are we nominally handling? It was probably
discussed and answered in C/C++11 standardization efforts?

Current HotSpot handles {ref, int, long} CASes. Atomics use either of
these, with notable implementation detail for AtomicBoolean that handles
*int*, not *boolean* field.

Do we seek extending CAS to all primitive typed-fields (with
complications for value types when they come)? Do we seek C/C++11
std::atomic behavior that seems to guarantee strong CAS for every
primitive specialization? Although I'm oblivious how that is implemented
in current C/C++ libraries and compilers.

Since VarHandles are the handles over fields, every object field may
expect to be pointed at by VarHandle. Therefore, it would be too late to
modify the object representation, without penalizing the memory
footprint for all objects. In other words, we cannot make boolean field
in all objects to take 4 bytes instead of 1 byte for a singular exotic
VH<boolean>.cas() usage.

Therefore, the question seems to be the hardware ability to make subword
CASes. At least x86 seems to be able to make the aligned sub-word CASes,
although I have not checked the performance for them -- but my gut
feeling is that it does not differ much, since CASes are cacheline-based
on most modern x86-s.

I mused a bit how to go forward in the absence of subword CASes. E.g.
make an aligned full-word CAS that contains the field, but that seems to
break the progress guarantees: two "strong" CASes on adjacent boolean
fields are not "strong", and one may fail spuriously. Or, e.g. locking
the object (words) for atomic operations, similarly to (late) fallback
strategy in AtomicLong for 32-bit systems, which is also not fun
implementation-wise.

Thanks,
-Aleksey