[jdk25u-dev] RFR: 8360540: nmethod entry barriers of new nmethods should be disarmed

[Roland Mesde]

On Fri, 9 Jan 2026 18:07:51 GMT, Roland Mesde <duke at openjdk.org> wrote:

> Backporting JDK-8360540: nmethod entry barriers of new nmethods should be disarmed
> 
> This PR addresses an optimization gap where nmethod entry barriers are unnecessarily executed for new methods in non-ZGC/non-ShenandoahGC collectors. Since JDK-8290025, all GCs use nmethod entry barriers, but only ZGC and ShenandoahGC properly disarm these barriers for new nmethods before first execution. The fix adds disarm calls for other GCs to match ZGC/ShenandoahGC behavior.
> 
> This backport has internal demand.
> 
> Ran related tests on linux-x64, linux-aarch64, macos-aarch64 and windows-x64:
> 
> make test TEST=test/hotspot/jtreg/vmTestbase/gc
> 
> Results attached:
> 
> [linux-x64-specific-test.log](https://github.com/user-attachments/files/24593990/linux-x64-specific-test.log)
> [macos-aarch64-specific-test.log](https://github.com/user-attachments/files/24593991/macos-aarch64-specific-test.log)
> [windows-x64-specific-test.log](https://github.com/user-attachments/files/24593992/windows-x64-specific-test.log)
> [linux-aarch64-specific-test.log](https://github.com/user-attachments/files/24593993/linux-aarch64-specific-test.log)

When JDK-8360540 is merged, G1 full garbage collection no longer marks nmethods that are currently on the stack, which could lead to premature code eviction issues, so a dependent PR is needed

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

PR Comment: https://git.openjdk.org/jdk25u-dev/pull/140#issuecomment-3745148746