Code review request: JDK-8005048,NMT: #loaded classes needs to just show the # defined classes

[Zhengyu Gu]

Hi,

I updated the webrev to reflect the suggestions.

Webrev: http://cr.openjdk.java.net/~zgu/8005048/webrev.01/

Thanks,

-Zhengyu


On 12/18/2012 10:39 AM, Zhengyu Gu wrote:
> Not likely, but I will convert it to loop, just to eliminate the 
> concerns ...
>
> Thanks,
>
> -Zhengyu
>
> On 12/18/2012 10:34 AM, Vitaly Davidovich wrote:
>>
>> By the way, no chance of blowing the stack here if small stack size 
>> is used, right?
>>
>> Sent from my phone
>>
>> On Dec 18, 2012 10:31 AM, "Vitaly Davidovich" <vitalyd at gmail.com 
>> <mailto:vitalyd at gmail.com>> wrote:
>>
>>     Ah yes, I see the destructor in MemRecorder now - thanks.
>>
>>     Sent from my phone
>>
>>     On Dec 18, 2012 9:54 AM, "Zhengyu Gu" <zhengyu.gu at oracle.com
>> <mailto:zhengyu.gu at oracle.com>> wrote:
>>
>>         Hi Vitaly,
>>
>>         Thanks for reviewing.
>>
>>         On 12/17/2012 7:24 PM, Vitaly Davidovich wrote:
>>>
>>>         Hi Zhengyu,
>>>
>>>         In GenerationData::reset() you delete _recorder_list.  Since
>>>         this list is built from callers (I.e. caller adds recorders)
>>>         is it good to delete the head here? I guess this class takes
>>>         ownership of added recorders?
>>>
>>         Yes, releasing recorder via
>>         MemTracker::release_thread_recorder() is cleaner solution, I
>>         will make change.
>>
>>
>>>         If so, who deletes the rest of the recorders in the list? I'd
>>>         expect to see a loop here deleting all recorders in the list.
>>>
>>         Recorder deletion in coded in recursive manner, in
>>         MemRecorer::~MemRecorder()
>>
>>         if (_next != NULL)  delete _next;
>>
>>         Thanks,
>>
>>         -Zhengyu
>>
>>
>>>         Thanks
>>>
>>>         Sent from my phone
>>>
>>>         On Dec 17, 2012 3:12 PM, "Zhengyu Gu" <zhengyu.gu at oracle.com
>>> <mailto:zhengyu.gu at oracle.com>> wrote:
>>>
>>>             Current NMT implementation reports number of loaded
>>>             classes at query time, but number of defined classes is
>>>             what is expected.
>>>
>>>             This changset reflects two major changes:
>>>
>>>             1. It counts number of defined classes vs. number of
>>>             loaded classes
>>>             2. It counts number of defined classes for each
>>>             generation, vs. counts at query time. In this way, the
>>>             number of defined classes that NMT reports, should match
>>>             the corresponding class metadata data. As the result, the
>>>             data should be more accurate.
>>>
>>>
>>>             Webrev:
>>>             http://cr.openjdk.java.net/~zgu/8005048/webrev.00/
>>> <http://cr.openjdk.java.net/%7Ezgu/8005048/webrev.00/>
>>>
>>>
>>>             Thanks,
>>>
>>>             -Zhengyu
>>>