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

[Chris Plummer]

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
>