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

[Thomas Schatzl]

On Thu, 3 Jul 2025 06:39:40 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> 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.

This has also been my concern when looking at this, however if ZGC/Shenandoah do not care, then (not directed at @albertnetymk , just in general) why should the others?
It would be nice to be uniform here (another random musing), either way is fine. Maybe the ZGC/Shenandoah devs can comment on this.

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

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