RFR: 8058176: [mlvm] tests should not allow code cache exhaustion [v2]

[Vladimir Ivanov]

On Thu, 4 Mar 2021 08:54:44 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Hi @TobiHartmann,
>> 
>> method handle intrinsics aren't regular java methods, otherwise, the failure to compile them won't result in `VirtualMachineError`. and, IIRC, their lifecycle is also different from that of nmethods, i.e. we don't sweep them. so I'm wondering why they can't go into non-nmethod segment.
>> 
>> -- Igor
>
> Yes, they are native wrappers but, in contrast to c2i/i2c adapters, they are still implemented as `nmethods`. I'm not a JSR292 expert but I think this is because they are potentially containing (meta)data that needs to be discovered when walking the code cache and iterator methods like `CodeCache::metadata_do` will only walk the `nmethod` heaps. They might also use other properties of `nmethods`. So I think the question would be more like "could native wrappers be implemented as `BufferBlobs`, similar to i2c/c2i adapters?"
> @iwanowww, what do you think?

I don't see a compelling reason why method handle linkers have to be nmethods and live in 'profiled'/'non-profiled' code heaps. I think the reason why it works that way now is the linkers are treated as ordinary native wrappers (since linker methods are just signature-polymorphic native static methods declared on `java.lang.invoke.MethodHandle` class). But native wrappers are represented as `nmethod`s for a reason: they can be unloaded along with the class. 
It's not the case with MH linkers which aren't unloaded at all. 

Please, file an RFE if you find it desirable to put MH linkers into 'non-nmethods' heap.

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

PR: https://git.openjdk.java.net/jdk/pull/2523