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