[jmm-dev] jdk9 APIs

Paul E. McKenney paulmck at linux.vnet.ibm.com
Fri Aug 14 16:03:50 UTC 2015


On Fri, Aug 14, 2015 at 06:44:27PM +0300, Aleksey Shipilev wrote:
> 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.

Thank you for the tutorial, makes perfect sense.

							Thanx, Paul



More information about the jmm-dev mailing list