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

[Evgeny Nikitin]

On Wed, 17 Feb 2021 15:46:44 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> Well, seems like rebalancing doesn't works that good. Here's a sample failure with plenty of free space in the non-nmethods heap:
>> 
>> [8.230s][warning][codecache] CodeHeap 'non-profiled nmethods' is full. Compiler has been disabled.
>> [8.230s][warning][codecache] Try increasing the code heap size using -XX:NonProfiledCodeHeapSize=
>> Java HotSpot(TM) 64-Bit Server VM warning: CodeHeap 'non-profiled nmethods' is full. Compiler has been disabled.
>> Java HotSpot(TM) 64-Bit Server VM warning: Try increasing the code heap size using -XX:NonProfiledCodeHeapSize=
>> CodeHeap 'non-profiled nmethods': size=8192Kb used=8191Kb max_used=8191Kb free=0Kb   << Exhausted
>> CodeHeap 'profiled nmethods': size=8192Kb used=8191Kb max_used=8191Kb free=0Kb       << Exhausted
>> CodeHeap 'non-nmethods': size=102400Kb used=18343Kb max_used=18343Kb free=84056Kb    << 84Mb of free space
>> 
>> # ERROR: Caught exception in Thread[Thread-41,5,MainThreadGroup]
>> ...
>> # ERROR: Caused by: java.lang.VirtualMachineError: Out of space in CodeCache for method handle intrinsic
>> The sum monitoring won't help here either. I've added non-nmethods heap to the monitoring, just to be sure.
>
> hm... that can mean that there is a product bug (or my recollections about code heaps aren't as good as I thought).
> 
> @TobiHartmann , @iwanowww, could you please take a look? Evgeny's observations suggest that method handle intrinsics use `non-profiled nmethods` and `profiled nmethods` heaps and not `non-nmethods` heap despite the fact that the last one has plenty of free space. my understanding is/was that we should have used `non-nmethods` heap for MH intrinsic 1st and if it's exhausted start to use the other heaps.
> 
> Thanks,
> -- Igor

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?

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

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