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

Thomas Stuefe stuefe at openjdk.org
Fri Jun 17 16:03:05 UTC 2022


On Fri, 17 Jun 2022 08:22:42 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> 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.

I would have thought that since we don't have the pool anymore, we can just remove this test line. The lines above already test against MaxMetaspaceSize.

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

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


More information about the serviceability-dev mailing list