RFR(S) 8186770: NMT: Report metadata information in NMT summary

[Zhengyu Gu]

Thanks, as always, Coleen.

-Zhengyu

On 09/27/2017 10:20 AM, coleen.phillimore at oracle.com wrote:
> This code seems good.  I can sponsor it for you.
> Coleen
> 
> 
> On 9/5/17 1:43 PM, Zhengyu Gu wrote:
>> 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
>>>
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 8186770.patch
Type: text/x-patch
Size: 15010 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20170928/ae6a1a15/8186770.patch>