RFR: 8210498: nmethod entry barriers

[Andrew Haley]

On 1/7/20 9:22 AM, erik.osterlund at oracle.com wrote:
> 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.

Aha! That'd be a much simpler method for AArch64, for sure. We already have
a nop at the start of every method, so we could rewrite it as a simple
jump.

> 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.

Totally. However, that walk is not inline in the mutator code, and there's
no reason not to run it concurrently.

> 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.

I'm not sure it [the alternative] does, exactly. It requires that
mutators see the changed jump once the cache flush has been done, but
that's less of a requirement than icache 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.

Sure, but there's little reason that oops should be embedded in the code
stream. It's an optimization, but a pretty minor one.

> 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.

i haven't seen that. Was it discussed anywhere? I'll ask him.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671