RFR(S): 8139673: NMT stack traces in output should show mt component

Zhengyu Gu zgu at redhat.com
Wed Jan 11 14:48:29 UTC 2017


Yes, this can work!

Thanks,

-Zhengyu


On 01/11/2017 09:13 AM, Coleen Phillimore wrote:
> I wonder if you can lookup the memory type with the stack trace in the 
> MallocSiteTable before creating a new one. Have the hash function 
> include the mtType.
> Coleen
>
>
> On 1/11/17 7:55 AM, Zhengyu Gu wrote:
>> Hi Chris,
>>
>> I am not convinced that 4 frames is sufficient, and skipping more 
>> frames can result ambiguous path.
>>
>> Or you may want to consider "OR" the memory types in the allocation 
>> site record, so it at least can report all possible memory types at 
>> this particular site.
>>
>> Thanks,
>>
>> -Zhengyu
>>
>>
>> On 01/10/2017 11:20 PM, Chris Plummer wrote:
>>> Hi Zhengyu,
>>>
>>> I think in theory you are right, but in practice probably each call 
>>> site is always using the same allocation type, as long as we are 
>>> going at least 4 frames back. If 4 frames is not enough, then either 
>>> we should be going back more frames, or we are not skipping enough 
>>> frames in some cases.
>>>
>>> thanks,
>>>
>>> Chris
>>>
>>> On 1/10/17 10:02 AM, Zhengyu Gu wrote:
>>>> I don't think that this enhancement makes sense. NMT only records 
>>>> last part of call path that leads memory allocation, which can be 
>>>> shared by many allocation paths and from
>>>> different sub systems.
>>>>
>>>> You are tagging the call site with the type of the first call, I 
>>>> think it can be misleading and incorrect.
>>>>
>>>> Thanks,
>>>>
>>>> -Zhengyu
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 01/10/2017 11:16 AM, Max Ockner wrote:
>>>>> Hello,
>>>>> Please review this small enhancement to NMT detail report. I have 
>>>>> added the memory type to the output for each NMT stacktrace.
>>>>>
>>>>> Bug:  https://bugs.openjdk.java.net/browse/JDK-8139673
>>>>> Webrev: http://cr.openjdk.java.net/~mockner/8139673/
>>>>>
>>>>> The old stacktrace output looks like this:
>>>>>
>>>>> [0x00007f17135fdd93] OSThread::pd_initialize()+0x63
>>>>> [0x00007f17135fdc7f] OSThread::OSThread(int (*)(void*), void*)+0x2f
>>>>> [0x00007f171360e020] os::create_thread(Thread*, os::ThreadType, 
>>>>> unsigned long)+0x80
>>>>> [0x00007f17139d1d3d] AbstractWorkGang::add_workers(unsigned int, 
>>>>> bool)+0x18d
>>>>>                              (malloc=2KB #10)
>>>>>
>>>>> The new stacktrace output looks like this:
>>>>>
>>>>> [0x00007f17135fdd93] OSThread::pd_initialize()+0x63
>>>>> [0x00007f17135fdc7f] OSThread::OSThread(int (*)(void*), void*)+0x2f
>>>>> [0x00007f171360e020] os::create_thread(Thread*, os::ThreadType, 
>>>>> unsigned long)+0x80
>>>>> [0x00007f17139d1d3d] AbstractWorkGang::add_workers(unsigned int, 
>>>>> bool)+0x18d
>>>>>                              (malloc=2KB type=Internal #10)
>>>>>
>>>>> Tested with jtreg NMT tests.
>>>>>
>>>>> Thanks,
>>>>> Max
>>>>
>>>
>>
>



More information about the hotspot-runtime-dev mailing list