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

[Tobias Hartmann]

On Wed, 3 Mar 2021 15:56:51 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> Sorry for missing the @TobiHartmann (I had github notifications disabled).
>> Unlike VM internal adapters/buffers/runtime stubs, Method handle intrinsics are actual Java methods that are compiled by the JIT and therefore need to go into the profiled or non-profiled code cache segment. They can not go into the non-nmethod segment.
>
> 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?

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

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