RFR: 8210498: nmethod entry barriers

[Andrew Haley]

On 10/05/2018 04:07 PM, Erik Österlund wrote:
> This implementation is for x86_64 and is based on the prototyping
> work of Rickard Bäckman. So big thanks to Rickard, who will
> co-author of this patch.
> The way it works is that there is a cmp #offset(r15_thread),
> simm32_epoch); je #continuation; inserted into the verified entry of
> nmethods that conditionally calls a stub trampolining into the VM.
> When the simm32_epoch is not equal to some TLS-local field, then a
> slow path is taken to run some barrier inside of the VM.  By
> changing this TLS-local field in the safepoint, all verified entries
> will take the slow path into the VM when run, where the barrier is
> eventually disarmed by patching the simm32_epoch value of the
> instruction stream to the current globally correct value.

OK. And because it's only triggered on a safepoint there is no need for
any memory fences.

> For the curious reader thinking that this might be an expensive
> operation, it is not. This check in the nmethod verified entry is
> very predictable and cheap. And because of use of inlining, the
> checks become more infrequent. In my evaluation, it has gone
> completely under the radar in benchmarking (running this with my
> current version of concurrent class unloading in ZGC).

I'm unconvinced. This change makes our entry/exit mechanism, already
rather heavyweight, even more so. I'm aware of the "below the noise"
argument but I don't think it's valid. Efficient systems are composed
of thousands of tiny optimizations, each one of which is too small to
produce any measurable benefit on its own. But they add up, or rather,
they multiply.

What's happening here, I suspect, is that branch prediction and
speculation logic in the x86 can often do the whole
lookahead/speculate cache line read/speculate branch sequence in
parallel with whatever else the method needs to do. If so, that's a
card you get to play, but only once.

Not that this is an argument against the patch: if we need to do it,
then we have to.

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