RFR: 8287135: Calculation of jmm_GetMemoryUsage is wrong [v4]

Yi Yang yyang at openjdk.org
Fri Jun 17 08:24:51 UTC 2022


On Fri, 17 Jun 2022 08:00:44 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   address Ioi's comments; fix LowMemoryTest2.sh failure
>
> test/jdk/java/lang/management/MemoryMXBean/LowMemoryTest2.sh line 74:
> 
>> 72: #  we would have committed the space right away and therefore the MemoryMXBean "committed" trigger
>> 73: #  would have fired. In the new Metaspace, we don't commit, so the MemoryMXBean does not fire.
>> 74: go -noclassgc -XX:MaxMetaspaceSize=4m LowMemoryTest2
> 
> Why did you reduce the MaxMetaspaceSize? (Should probably be okay post JEP-387, but how does it relate to your change?)

Maybe I misunderstand the purpose of LowMemoryTest2?

I thought the original test case 

go -noclassgc -XX:MaxMetaspaceSize=16m -XX:CompressedClassSpaceSize=4m LowMemoryTest2

is used to check if low memory ratio(20% remaining) of compressed class pool could be detected instead of throwing Compressed Class Space OOM. Since we don't have compressed class pool anymore, I thought metaspace should be reduced to adapt original purpose of that test case.

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

PR: https://git.openjdk.org/jdk/pull/8831


More information about the serviceability-dev mailing list