On Thu, 26 May 2022 05:08:13 GMT, Ioi Lam <ik...@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

Reply via email to