RFR: 8334247: [PPC64] Consider trap based nmethod entry barriers [v5]

[Richard Reingruber]

On Wed, 10 Sep 2025 13:33:20 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> We can shrink nmethod entry barriers to 4 instructions (from 8) using conditional trap instructions. Some benchmarks seem to show very small improvements. At least the code size reduction is an advantage.
>
> Martin Doerr has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Merge remote-tracking branch 'origin' into 8334247_PPC64_trap_based_nmethod_entry_barrier
>  - Merge remote-tracking branch 'origin' into 8334247_PPC64_trap_based_nmethod_entry_barrier
>  - Move nmethod entry barrier code up in the signal handler.
>  - Merge remote-tracking branch 'origin' into 8334247_PPC64_trap_based_nmethod_entry_barrier
>  - Merge remote-tracking branch 'origin' into 8334247_PPC64_trap_based_nmethod_entry_barrier
>  - 8334247: [PPC64] Consider trap based nmethod entry barriers

Thanks for sharing the results.

> Hi, @reinrich I checked with Dacapo benchmark in aix-ppc64. There is a significant decrease in benchmark runtime(sec) after the patch.

So the numbers are benchmark runtime(sec), correct? Looking at the fist 2 columns I read that with G1 the runtime of the *tomcat* benchmark is reduced from 85s to 1.4s by the change. This doesn't sound plausible to me. Am I misinterpreting the results?

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

PR Comment: https://git.openjdk.org/jdk/pull/24135#issuecomment-3346424001