[aarch64-port-dev ] RFR: 8189596: AArch64: implementation for Thread-local handshakes

[Andrew Dinn]

On 24/11/17 13:36, Erik Österlund wrote:
> On 2017-11-24 13:07, Andrew Dinn wrote:
>> On 24/11/17 10:36, Erik Österlund wrote:
>>> By placing loading the local poll value with ldar *only* in the native
>>> wrapper wakeup function, you avoid these issues.
>>> Another approach you may elect to use is to only in the native wrapper
>>> load both the thread-local poll value and the
>>> SafepointSynchronize::_state, when filtering slow paths to avoid this
>>> unfortunate race.
>> I can see why an ldar (actually ldarw) is needed when safepoint_poll is
>> called from the nativewrapper. Can you explain why ldar is not needed
>> for *all* calls to safepoint_poll?
> 
> That is a long story. :) But since you asked, here we go...
> . . .
> I hope this sheds some light on the important races you need to be aware
> of.

Well, that's a good story and maybe needs to be included somewhere in
the code even if only in precis. The asymmetry between start and end
makes clear why you want an ldar in the native wrapper.

The one detail I am still not sure of is how this design ensures that
the benign races in JIT/interpreter ever come to an end. What guarantees
that JITted code or the interpreter actually performs an acquiring load
and thereby notices a change to the armed poll value? That might take a
very long time (if it happens at all?).

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander