jdk.internal.misc.Unsafe.weakCompareAndSwapObject

Andrew Haley aph at redhat.com
Wed Feb 24 18:31:22 UTC 2016


On 02/24/2016 06:11 PM, Aleksey Shipilev wrote:
> Current simplistic implementation does only emit surrounding barriers
> around CAS/CAE nodes. Even that change was enough of a headache to get
> right.
> 
> We were optimistically hoping that you can match the surrounding
> barriers into the weaker CAS/CAE form, when weaker barriers are around
> the CAS/CAE node. But either way, we could also split CAS/CAE into
> multiple {none, acq, rel, acqrel} nodes and match them directly -- which
> might both be the conceptually cleaner, and much more intrusive change.

Aha!  OK, I understand it now.

Well, we certainly have all of the machinery to do that.  However, I
was rather hoping that in the long run we could do it the other way
around: get rid of most of these memory barriers in the compiler.
Instead we could have LoadAcquire, StoreRelease, and so on.  The back
ends could then expand them into whatever instructions were necessary.
Of course, the optimizers would have to respect the barrier effects of
these nodes.

That would be much cleaner and simpler -- not to mention easier to get
right -- than what we have today.

Andrew.


More information about the hotspot-dev mailing list