RFR: 8210498: nmethod entry barriers

[erik.osterlund at oracle.com]

Hi Andrew,

On 1/6/20 7:16 PM, Andrew Haley wrote:
> On 10/8/18 1:54 PM, Erik Österlund wrote:
>> Also note that the implementation space of the barrier itself has some
>> flexibility. Rickard's first prototype involved having an unconditional
>> branch patched in over a nop. Since the nop is removed in the frontend,
>> it seemed like the most conservative starting point. But since there was
>> no measurable difference to the conditional branch, that was more
>> favourable in the end, since it hade the additional advantage of not
>> requiring a code cache walk in the safepoint. But if you have a platform
>> where the trade off is not as obvious, both mechanisms could easily be
>> supported.
> Can you describe this mechanism a little more? I don't really understand
> how that would work, even on x86.

Presuming you would like to hear about the solution we didn't go for 
(unconditional branch)...

The nmethod entry barriers are armed in a safepoint operation. Today 
that safepoint operation
flips some epoch counter that the conditional branch will consider armed 
once the safepoint is
released.

In the alternative solution that biases the cost towards arming, instead 
of calling, you would
instead walk the code cache and explicitly arm nmethods by patching in a 
jump over nops in the
verified entry (for all nmethods).

Disarming would be done by patching back nops over the jump on 
individual nmethods as they
become safe to disarm.

In the end, the hypothetical overhead of performing a conditional branch 
instead of executing
nops was never observed to make a difference, and therefore we went with 
the conditional branch
as the latency cost of walking the code cache was conversely not 
hypothetical.

Note that since the entry barrier is used to protect mutators from 
observing stale oops, the
current solution (and this alternative solution) relies on instruction 
cache coherency. Since
there are oops embedded in the code stream, we rely on the disarming 
being a code modification
such that a mutator observing the disarmed barrier implies it will also 
observe the fixed oops.

If you are looking for an AArch64 solution, Stuart Monteith is cooking 
up a solution that we
discussed, which does not rely on that for AArch64, which you might be 
interested in. Although,
perhaps that is not what you are fishing for.

Hope this helps.

Thanks,
/Erik