[jmm-dev] jdk9 APIs

[Paul E. McKenney]

On Wed, Aug 12, 2015 at 10:38:10AM -0400, Doug Lea wrote:
> On 08/12/2015 05:02 AM, Aleksey Shipilev wrote:
> >On 08/10/2015 09:22 PM, Doug Lea wrote:
> 
> >>     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?
> 
> The answers need to be a little different for Java and C++.
> In C++, you can only apply to "atomic" types.
> 
> Under the  current VarHandle scheme, you can attach to
> anything at compile time, but methods may bail out
> throwing an UnsupportedOperationException at run-time.
> 
> This will always occur for example when applying getAndAdd
> to a VarHandle of any Object type.
> 
> This was apparently the tradeoff most acceptable to all concerned.
> It means that in addition to memory-model-related specs,
> the methods will need to carry warnings that they might
> just throw UOE; hopefully enumerating common cases
> like CAS for sub-word types and unaligned memory.
> 
> >Therefore, the question seems to be the hardware ability to make subword
> >CASes.
> 
> My understanding (and preference) is that trying to CAS with
> VarHandles to bytes and other small types just throws
> UOE and should be spec'ed to do so.

OK, I will bite...  Why can't you just apply a CAS instruction to the
larger word containing the subword?

							Thanx, Paul