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

coleen.phillimore at oracle.com coleen.phillimore at oracle.com
Wed Sep 27 14:20:05 UTC 2017


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
>>



More information about the hotspot-runtime-dev mailing list