RFR: 8290062: Remove nmethodLocker for nmethods on-stack

[Vladimir Kozlov]

On Mon, 11 Jul 2022 07:49:09 GMT, Axel Boldt-Christmas <duke at openjdk.org> wrote:

> From JBS:
> 
>> The nmethodLocker is pretty nasty as it prevents an nmethod from being freed, but without really keeping it alive. We would like to minimize its use. The most obvious places where it can be removed, is when "protecting" nmethods that are already on-stack. Neither the sweeper nor the GC is interested in making nmethods on-stack not live. These ones simply do not do anything.
> 
> Removed the `nmethodLocker` where the nmethod is a caller on the stack.

nmethod could be marked for deoptimization (`non_entrant`) even if it has stack frame.
`nmethod::make_not_entrant_or_zombie()` uses `nmethodLocker` for that.
There are other changes to nmethod code could be done under this lock.

How you determined which `nmethodLocker` could be safely removed?

This should be tested with a lot of tiers (at least up to tier 7). Add testing link to RFE.

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

PR: https://git.openjdk.org/jdk/pull/9444