RFR(XXS) 8187629: NMT: Memory miscounting in compiler (C2)

[Zhengyu Gu]

Hi Vladimir,

I filed a bug to track this issue.

https://bugs.openjdk.java.net/browse/JDK-8187685

Thanks,

-Zhengyu

On 09/19/2017 12:52 PM, Vladimir Kozlov wrote:
> On 9/19/17 9:36 AM, Zhengyu Gu wrote:
>> Hi Vladimir,
>>
>>
>> On 09/19/2017 12:14 PM, Vladimir Kozlov wrote:
>>> Compilers also use a lot thread local ResourceArea - 
>>> Thread::current()->resource_area() and NEW_RESOURCE_ARRAY() macro.
>>> But thread local area is defined as mtThread:
>>>
>>> http://hg.openjdk.java.net/jdk10/hs/hotspot/file/5ab7a67bc155/src/share/vm/runtime/thread.cpp#l218 
>>
>>
>>
>> Thread's resource area is general purpose per-thread storage and used 
>> by many subsystems. Unfortunately, NMT has no way to distinguish the 
>> users at this moment, categorizing as mThread is sort of placeholder.
>>
>> I am welcome to any suggestions
> 
> Thread() is called from CompilerThread() and we can pass a parameter to 
> indicate user. Or add a virtual method to Thread class to check type of 
> thread.
> 
> In the past we had compiler local changes to get information how much 
> memory was used during compilation but it was never get pushed. We 
> accessed Arena::_bytes_allocated for that.
> 
> Thanks,
> Vladimir
> 
>>
>> Thanks,
>>
>> -Zhengyu
>>
>>
>>>
>>>
>>> Vladimir
>>>
>>> On 9/18/17 12:17 PM, Zhengyu Gu wrote:
>>>> Compiler (C2) uses ResourceArea instead of Arena in some 
>>>> circumstances, so it can take advantage of ResourceMark. However, 
>>>> ResourceArea is tagged as mtThread, that results those memory is 
>>>> miscounted by NMT
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8187629
>>>> Webrev: http://cr.openjdk.java.net/~zgu/8187629/webrev.00/
>>>>
>>>>
>>>> Test:
>>>>
>>>>    hotspot_tier1 (fastdebug and release) on Linux x64
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> -Zhengyu