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

[Igor Ignatyev]

On Wed, 3 Mar 2021 12:40:30 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> I inspected sample built up cache with 'Compiler.CodeHeap_Analytics' diagnostic command. The vast majority of the 'non-profiled nmethods' heap are zillions of `invokeBasic`, `linkToStatic` and similar, with different signatures. Dump shows something like this:
>> 
>> nMethod (active)    invokeBasic(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
>> nMethod (active)    invokeBasic(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;DFJD)Ljava/lang/Object;
>> nMethod (active)    invokeBasic(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;DFJDLjava/lang/Object;)Ljava/lang/Object;
>> nMethod (active)    invokeBasic(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;DFJDLjava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
>> 
>> ... with their signatures marching to the right screen border and beyond. Given that their arguments are mish-mashed in all possible combinations, there are really many of them (I've been able to build up cashes up to 300MB without a pair signatures repeating). They are nmethods, and should be in the nmethods cache, aren't they?
>
> 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

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

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