RFR: 8291237: Encapsulate nmethod Deoptimization logic [v2]

[Erik Österlund]

On Wed, 3 Aug 2022 20:42:59 GMT, Erik Österlund <eosterlund at openjdk.org> wrote:

>> Axel Boldt-Christmas has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Add assertions
>>  - Fix marked logic
>>  - Erik refactorings
>
> Also, in DeoptimizationContext::deopt_compiled_methods, the SweeperBlocker completely blocks out the sweeper from running. But as I mentioned, even without that, without safepoint checks, we can never flush these things.
> It's worth mentioning that there used to be a special case for OSR nmethods that they could be flushed immediately and skip the zombie step. But I removed that a few tears ago so we wouldn't have to think about that pathological case separately.

> @fisk, is there any chance that in the future we might figure out how to allow nmethods to be flushed without a safepoint?  Maybe with handshakes or some other clever improvement?  If no, then maybe a comment saying so would help.  If yes, then are there some asserts we could add that would catch such a change?  

Yes. With concurrent class unloading, nmethods are unloaded during concurrent execution. After the sweeper removal, this is done in 2 phases:
1. We unlink() the nmethod
2. A thread-local handshake with all JavaThreads (who might have gotten a reference to it before unlinking)
3. We flush() the nmethod

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

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