RFR(S) 8186770: NMT: Report metadata information in NMT summary
Zhengyu Gu
zgu at redhat.com
Tue Sep 5 17:43:32 UTC 2017
Hi Andrew,
Thanks for the review and suggestions. The webrev is updated according
to the discussions.
Webrev: http://cr.openjdk.java.net/~zgu/8186770/webrev.01/index.html
The sample outputs:
Summary:
- Class (reserved=1074360KB, committed=28856KB)
(classes #4028)
(malloc=1208KB #16218)
(mmap: reserved=1073152KB, committed=27648KB)
( Metadata: )
( reserved=24576KB, committed=24320KB)
( used=20914KB)
( free=3295KB)
( waste=111KB =0.46%)
( Class space:)
( reserved=1048576KB, committed=3328KB)
( used=2649KB)
( free=679KB)
( waste=0KB =0.00%)
Summary diff:
- Class (reserved=1076455KB +2129KB,
committed=29415KB +849KB)
(classes #4037 +13)
(malloc=1255KB +81KB #17477 +2214)
(mmap: reserved=1075200KB +2048KB,
committed=28160KB +768KB)
( Metadata: )
( reserved=26624KB +2048KB,
committed=24832KB +768KB)
( used=21368KB +718KB)
( free=3336KB -21KB)
( waste=128KB =0.52% +71KB)
( Class space:)
( reserved=1048576KB, committed=3328KB)
( used=2654KB +7KB)
( free=674KB -7KB)
( waste=0KB =0.00%)
Thanks,
-Zhengyu
On 09/05/2017 11:18 AM, Andrew Dinn wrote:
> On 29/08/17 17:31, Zhengyu Gu wrote:
>> Okay, I see what you mean. But in this case, capacity = committed.
>
> Well, it does not always seem to be exactly the same. If you add up all
> the pieces to derive the capacity then it sometimes seems to fall short
> of committed. I looked deeper into this and found that sometimes the
> difference is down to rounding up/down. However, there also seems
> occasionally to be more space unaccounted for that cannot be explained
> by rounding errors.
>
> I looked into your suggestion that this might be accounted for by 'dark
> matter' i.e. tail ends of a chunk left unused when the last block is
> carved out and the chunk retired because the tail is too small to insert
> into the block dictionary. However, from my reading of the code I think
> that any such 'dark matter' will still to show up in the waste space count.
>
> Rather than hold up this current change I'd prefer to see it pushed and
> address the arithmetic problem in a follow-up issue. Even with an
> occasional small disparity in the reported figures I think it is really
> helpful to have this detailed info available as part of the NMT output.
>
>> I wonder if it is cleaner that just reports free, used and waste, e.g.
>>
>> ( Metadata: )
>> ( reserved=22528KB, committed=21504KB)
>> ( used=20654KB)
>> ( free=786KBKB)
>> ( waste=64KB =0.30%)
>>
>> where free = (capacity - used) + free_chunks + available
>> waste = committed - capacity - free_chunks - available
>> total = committed
> Yes, I agree that it's ok to leave the available figure implicit -- it
> is easily computed from the committed total by subtracting used and
> waste (that's only correct modulo the occasional small disparity between
> capacity and committed but the difference is small enough not to be
> significant). So, I'm happy with this version.
>
> regards,
>
>
> Andrew Dinn
> -----------
> Senior Principal Software Engineer
> Red Hat UK Ltd
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
>
More information about the hotspot-runtime-dev
mailing list