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

Sorna Sarathi N ssarathi at openjdk.org
Wed Oct 8 07:21:12 UTC 2025


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

I've re-ran the benchmarks after fixing the java version issue. The updated results show slight but consistent performance improvements across most benchmarks with trap build compared to master baseline, and no regressions were observed.

It indicates the changes bring low level efficiency gain - the fix optimises general runtime behaviour rather than any GC specific tuning. 
<img width="1400" height="800" alt="gc_runtime_heatmap-final" src="https://github.com/user-attachments/assets/65017782-74fe-4781-acea-779425010ee6" />

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

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


More information about the hotspot-dev mailing list