RFR: 8290688: Optimize x86_64 nmethod entry barriers [v4]

[Richard Reingruber]

On Wed, 20 Jul 2022 16:34:51 GMT, Erik Österlund <eosterlund at openjdk.org> wrote:

>> The current x86_64 nmethod entry barrier is good, but it could be a bit better. In particular, this enhancement targets the following ideas.
>> 
>> 1. The alignment of the cmp instruction is 8 bytes. However, we only patch 4 bytes and the instruction length is always 8 bytes. So if we align the start of the instruction to 4 bytes only, that is enough to ensure that the immediate part of the instruction is 4 byte aligned, which is all we need (cf. http://cr.openjdk.java.net/~jrose/jvm/hotspot-cmc.html).
>> 
>> 2. Today the fast path (conditionally) jumps over a call to a stub. It is not uncommon for the branch not taken path being better optimized, making it favourable to move the call to a stub out-of-line. This has the additional benefit of not polluting the instruction caches at the nmethod entry with instructions not used in the fast path. A bit messy but we can do it for at least C2 code.
>> 
>> 3. For C1 and native wrappers, I don't think they are hot enough to warrant the stub machinery. But at least the jump that jumps over the cold stuff, can be shortened. I can get behind that.
>> 
>> Before addressing this, turning nmethod entry barriers on with G1 (e.g. by enabling loom) leads to a regression in DaCapo tradesoap-large. With this enhancement, the regression goes away, so that the cost of nmethod entry barriers is not visible.
>
> Erik Österlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixing 32 bit build again

Hi Erik,

Looks good to me!

I can imagine that hot taken branches, especially many of them, can become a
performance issue when the hardware fails to predict the target address.

Richard.

-------------

Marked as reviewed by rrich (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9569