RFR: 8360540: nmethod entry barriers of new nmethods should be disarmed

[Albert Mingkun Yang]

On Wed, 25 Jun 2025 14:55:03 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Adding `disarm` calls as ZGC and ShenandoahGC already have (see JBS issue for more details). Tier1-4 tests have passed.
> 
> I will need reviews from GC experts to check for potentially problematic side effects.
> Note that `rebuild_code_roots()` disarms all nmethods during `G1FullCollector::complete_collection`, now.
> 
> Some stats (nmethod entry barrier hits in jvm98 with/without patch):
> 
> | GC       | before | after |
> | -------- | ------ | ----- |
> | G1       |   3339 |   127 |
> | Parallel |   3223 |  1141 |
> | Serial   |   3206 |  1142 |

My understanding on how arming-at-marking-end works is that java threads will hit those armed nmethods after full-gc-pause-end, run nmethod-entry-barrier, and mark them as "hot" (`mark_as_maybe_on_stack`), then in the next full-gc, unloading logic will identify those "hot" nmethods and not unload them. IOW, we use the btw-full-gc window to measure nmethod-temperature.

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

PR Comment: https://git.openjdk.org/jdk/pull/25982#issuecomment-3031053820