RFR: 8287135: Calculation of jmm_GetMemoryUsage is wrong

Yi Yang yyang at openjdk.java.net
Thu May 26 06:02:42 UTC 2022


On Thu, 26 May 2022 05:08:13 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> It seems that calculation of MemoryMXBean.getNonHeapMemoryUsage(jmm_GetMemoryUsage) is wrong.
>> 
>> Currently, `NonHeapUsage=CodeCache+Metaspace(ClassTypeSpace+NonClassTypeSpace)+CompressedClassSpace(ClassTypeSpace)`
>> 
>> ==> CodeHeap 'non-nmethods' 1532544 (Used)
>> ==> CodeHeap 'profiled nmethods' 0
>> ==> CodeHeap 'non-profiled nmethods' 13952
>> ==> Metaspace 506696
>> ==> Compressed Class Space 43312
>> init = 7667712(7488K) used = 2096504(2047K) committed = 8454144(8256K) max = -1(-1K)
>> 
>> In this way, getNonHeapMemoryUsage is larger than it ought to be, it should be `NonHeapUsage = CodeCache + Metaspace`.
>
> src/hotspot/share/services/management.cpp line 753:
> 
>> 751:     for (int i = 0; i < MemoryService::num_memory_pools(); i++) {
>> 752:       MemoryPool* pool = MemoryService::get_memory_pool(i);
>> 753:       if (pool->is_codeheap() || pool->is_metaspace()) {
> 
> Our only special case is that all the memory reported by `CompressedKlassSpacePool` are already reported by `MetaspacePool`, so shouldn't we do this:
> 
> 
> if (pool->is_non_heap() && !pool->is_compressed_klass_space()) {
>   // skip CompressedKlassSpacePool since its memory is already reported by
>   // MetaspacePool

This is also acceptable, but if we add more memory pools, we might add more special pools to exclude their space from nonheap. Instead, we can specify exactly which pools we need to accumulate, which is what this change did.

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

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


More information about the serviceability-dev mailing list