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

Evgeny Nikitin enikitin at openjdk.java.net
Tue Feb 16 19:32:44 UTC 2021


On Fri, 12 Feb 2021 20:03:01 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> Evgeny Nikitin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Switch to ManagementBeans approach instead of the WhiteBox one
>
> 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.

> test/hotspot/jtreg/vmTestbase/vm/mlvm/meth/share/MHTransformationGen.java line 107:
> 
>> 105:             if (isCodeCacheEffectivelyFull()) {
>> 106:                 Env.traceNormal("Not enought code cache to build up MH sequences anymore. " +
>> 107:                         " Has only been able to achieve " + (MAX_CYCLES - i) + " out of " + MAX_CYCLES);
> 
> given `nextInt(x)` returns a random number from `[0; x]`, we might have achieved more (or less) `MAX_CYCLES - i`, i.e. that part of the message is incorrect, I'd just remove it.

Fixed by extracting the generated random number first.

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

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


More information about the hotspot-dev mailing list