RFR: 8295724: VirtualMachineError: Out of space in CodeCache for method handle intrinsic [v6]

[Dean Long]

On Tue, 8 Nov 2022 18:42:32 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Hmm. The GC used to walk all nmethods an ensure the is_unloading_state is computed for all of them. When using a STW collector, we will crash if trying to compute this outside of the UnloadingScope, as we then don't have rnough information to be able to compute it. So I suppose this is a bit fragile; if an nmethod is acquired from outside of an nmethod iterator, and the is_unloading() question is asked, we risk crashing.
>> I suppose we could strengthen this by letting is_unloading() know rhat the answer is false for method handle intrinsics.
>> It feels more and more like method handle intrinsics shouldn't be nmethods as more and more code that deals with nmethods needs to know that this isn't really an nmethod. Although that's not a new observation for this patch.
>
> So, calling `IsUnloadingBehaviour::is_unloading` is unsafe. Should we only call it when `is_permanent_class_loader_data()` for the method returns false?

Does this also mean that nmethods for method handle intrinsics could previously get unloaded when they became "cold", and now if they are in NonNMethod they live forever?  Someone could probably write a test that fills up NonNMethod with method handle intrinsics for various signatures by spinning up temporary classes with random signatures.

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

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