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