[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-hotspot-runtime-dev
Subject:    Re: RFR(S): 8139673: NMT stack traces in output should show mt component
From:       Chris Plummer <chris.plummer () oracle ! com>
Date:       2017-01-11 17:42:31
Message-ID: 2e77dbcd-bab8-86e9-e43d-c5e39204fe1e () oracle ! com
[Download RAW message or body]

I would suggest doing a test run with a check to see if this is even 
needed. The call sites are static, so if you are sufficiently testing 
NMT, then you should hit every call site that uses NMT.

Chris

On 1/11/17 6: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
>>>>
>>>
>>
>

[prev in list] [next in list] [prev in thread] [next in thread]