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

[Evgeny Nikitin]

On Thu, 4 Mar 2021 13:15:59 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> 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.

Raised the RFE: https://bugs.openjdk.java.net/browse/JDK-8263377

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

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