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

[Igor Ignatyev]

On Tue, 16 Feb 2021 19:29:42 GMT, Evgeny Nikitin <enikitin at openjdk.org> wrote:

>> test/hotspot/jtreg/vmTestbase/vm/mlvm/meth/share/MHTransformationGen.java line 69:
>> 
>>> 67:     private static final boolean USE_THROW_CATCH = false; // Test bugs
>>> 68: 
>>> 69:     private static final MemoryPoolMXBean CODE_CACHE_MX_BEAN = ManagementFactory
>> 
>> does it work w/ both `-XX:+SegmentedCodeCache` and `-XX:-SegmentedCodeCache`? 
>> If I remember correctly (@TobiHartmann , please correct me if I'm wrong), `CodeCache` pool exists when `SegmentedCodeCache` is disabled, when it's enabled, you will have 3 different pools (one for each "CodeHeap"), and here we would need to use one for `non-nmethod` codeheap.
>> 
>> -- Igor
>
> Thanks for the info about the segmented code cache. I did some research and found that the opposite is true - both nmethod pools ('profiled' and 'non-profiled') are growing along with the MH graph growth. This is supported by the specification for non-method code heap at:
> 
> https://docs.oracle.com/en/java/javase/15/vm/java-hotspot-virtual-machine-performance-enhancements.html#GUID-1D9B26AD-8E0A-4771-90DA-A81A2C1F5B55
> 
> Please check the the fixed version.

o/c they grow, b/c we use them for compiled code *and* if there is no space in non-nmethod heap, we use them for adapters as well, so I guess that the growth that you see is already after non-nmethod heap got exhausted. I'd recommend you simply use the sum of all available code-heaps (this will increase the possibility of false-positive results due to segmentation, but I don't think it matters much here).

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

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