RFR: 8291718: Remove mark_for_deoptimization from klass unloading [v5]

[Erik Österlund]

On Fri, 5 Aug 2022 02:34:49 GMT, Dean Long <dlong at openjdk.org> wrote:

>> I would like to find out more in detail what you want to ensure, or situation you are afraid that might occur. 
>> 
>> I've tried to investigate what types of dependent nmethods are not `unloading` when the the klass with a dependency is unloaded. I suspect it has to do with class loading and compilation order. From what I understand the nmethod will only be unloading if it has a reference to a dead oop inside it. So the compiler must generate code which is dependent without having an oop baked in. 
>> 
>> I do find it difficult to reason about the lifetime of these dependencies (at least the logical part, the release, purge cycle of the memory seems pretty straight forward) and nmethods (the sweeper removal does make the nmethod lifecycle a lot easier to reason about tough). 
>> 
>> I am really interested in what you think. As this change is just always running an edge case which can happen in mainline. This just makes it default. Hotspot seems to have relied on this interaction being this way for some time. 
>> 
>> The windows machines finally woke up and the patch passed tier 1-7
>
> My concern was that we could be removing the dependencies from nmethods that are still using them.  But if that was the case, the old code would have the same problem.

The compiler dependencies are protecting against loading of a class that is a subtype of X. If X is unloaded, then we can be pretty sure nobody is going to load a subclass of X.

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

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