[jmm-dev] jdk9 APIs

[Aleksey Shipilev]

On 14.08.2015 18:39, Paul E. McKenney wrote:
> 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?

As I tried to explain before, this seems to break the guarantees for
strong CAS, that at least one of the CASes against the same location
should succeed. The trick here is that on Java level, "location" is
defined as "field" or something like that.

Case in point: imagine you have two subword-sized fields in the same
word, and you do CAS on each of them. From Java level, these CASes are
uncontended, and both should succeed. In our hypothetical
implementation, one of the CASes would fail. This is a good thing for
weakCAS that is spec-ed to allow spurious failures, but not for a strong
one.

Thanks,
-Aleksey