On Wed, 3 Aug 2022 20:42:59 GMT, Erik Österlund <eosterl...@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
