Code review request: CR 6995781 Native Memory Tracking Phase 1

[Vladimir Kozlov]

Zhengyu, Coleen

Did your investigated possibility of using something like ResourceMark mechanism 
to tag memory usage? In general new changes are good.

Thanks,
Vladimir

Coleen Phillmore wrote:
> 
> Hi,
> We are investigating your issue about requiring a memory tag for every 
> NEW_C_HEAP_ARRAY call, and appreciate the pain that merging this change 
> will be.   The reason for requiring this parameter is so native tracking 
> is more accurate, but maybe there's an alternative.
> Coleen
> 
> On 6/28/2012 2:57 AM, Thomas Stüfe wrote:
>> On Thu, Jun 28, 2012 at 4:11 AM, David 
>> Holmes<david.holmes at oracle.com>  wrote:
>>> Hi Zhengyu,
>>>
>>> Two queries:
>>>
>>> 1. Why were all the os::*memory* functions renamed as os::pd_*memory* ?
>>>
>>> 2. In jvmg.make on all platforms we unconditionally add 
>>> -D_NMT_NOINLINE_ to
>>> inform NMT that no inlining is done by the compiler. How do we know 
>>> that? Is
>>> there some specific compiler flag that controls this? If so the 
>>> setting of
>>> -D_NMT_NOINLINE_ should be conditional on that flag being set. As you 
>>> can
>>> override flag settings at build-time it would seem possible to me set
>>> -D_NMT_NOINLINE_ incorrectly.
>>>
>>> General comment which I'm sure you've had before: it is a real shame 
>>> that
>>> every NEW/FREE_C_HEAP_ARRAY etc had to be modified to add a tag - and it
>>> seems the majority of them are mtInternal. Could we not define the 
>>> existing
>>> macros to add mtInternal, and then define new macros, eg
>>> NEW_C_HEAP_ARRAY_TAGGED, for explicit tagging for use when not 
>>> mtInternal?
>> I have to agree to that. You did explain your motives before, and they
>> are valid. However, I think a lot of people will forget the new
>> arguments and will waste time to go thru that extra correction step
>> time and time again - they may hate you for that :-)
>>
>> Also, for people like us (we maintain a customized "fork" of the
>> hotspot we constantly merge with the real hotspot), "shotgun"-like
>> changes to the code base cause a lot of merging work. Of course, that
>> is our problem, not yours, but I still would be happy if the changes
>> were less invasive.
>>
>> Kind Regards,
>>
>> Thomas Stuefe
>> SAP Germany
>>
>>> Thanks,
>>> David
>>> -----
>>>
>>>
>>> On 28/06/2012 11:32 AM, Zhengyu Gu wrote:
>>>> Hi,
>>>>
>>>> Sorry for the long delay, here is the updated webrev:
>>>> http://cr.openjdk.java.net/~zgu/6995781/webrev.01
>>>>
>>>> Thanks for many people who take time to review NMT code, the new webrev
>>>> reflects the comments and suggestions from you, along with the fixes of
>>>> serviceability agent and some bugs.
>>>>
>>>> Thanks,
>>>>
>>>> -Zhengyu
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 6/12/2012 12:11 PM, Zhengyu Gu wrote:
>>>>> This is the webrev for native memory tracking phase 1, which is
>>>>> tracked by CR6995781
>>>>> (http://monaco.us.oracle.com/detail.jsf?cr=6995781) and related DCmd
>>>>> CR7151532 (http://monaco.us.oracle.com/detail.jsf?cr=7151532).
>>>>>
>>>>> Native memory tracking (NMT) phase 1, is designed to track native
>>>>> memory (malloc'd and mmap'd) usages by VM code only, it does not track
>>>>> the memory usages by libraries and JNI code.
>>>>>
>>>>> On the implementation side, NMT intercepts memory related calls in os
>>>>> implementation, such as os::malloc, os::realloc, os::free,
>>>>> os::reserve_memory, os::commit_memory and etc. the caller is required
>>>>> to provide the 'memory type' information, which represents the VM
>>>>> subsystem that the memory is allocated for. The 'memory type' is
>>>>> defined in /src/share/memory/allocation.hpp. Also, a caller's pc is
>>>>> captured if NMT tracking level is set to detail.
>>>>>
>>>>> There are a few ways to tag a memory block to a memory type:
>>>>>
>>>>> 1. os::malloc takes an extra parameter for the memory type.
>>>>> 2. CHeapObj now is a template, it takes a memory type as template
>>>>> parameter to tag the object to a specified memory type.
>>>>> 3. Utility classes, such as Arena, GrowableArray and etc. the memory
>>>>> type is a parameter of 'new' operator.
>>>>> 4. Virtual memory block is tagged on its base address.
>>>>>
>>>>> When NMT intercepts the call, a memory record is created and
>>>>> serialized by a sequence number, generated by global sequence
>>>>> generator. The memory record is written to a per-thread recorder
>>>>> without a lock, when calling thread is a 'safepoint visible'
>>>>> JavaThread - a JavaThread that will block at safepoint. Otherwise,
>>>>> ThreadCritical lock is acquired to write to a global recorder. The
>>>>> recorders (or raw data) are synchronized at some safepoints, and
>>>>> global sequence generator is also reset at synchronization time, to
>>>>> avoid overflow the sequence number.
>>>>>
>>>>> A dedicated NMT worker thread is created to process the raw memory
>>>>> records. It first stages a generation of raw data (a generation is
>>>>> defined as span between resets of global sequence number), then
>>>>> promotes the staged data to a global snapshot, which maintains
>>>>> information of all 'live' memory block.
>>>>>
>>>>> NMT Tracking option has to be specified through VM command line option
>>>>> -XX:NativeMemoryTracking (off by default), tracking level can not be
>>>>> altered during runtime, but it can be shutdown through jcmd tool.
>>>>>
>>>>> NMT DCmd implements a set of sub-command to control NMT runtime and
>>>>> request tracking data.
>>>>>
>>>>> Webrev: http://cr.openjdk.java.net/~zgu/6995781/webrev.00
>>>>>
>>>>> The tests and results:
>>>>>
>>>>> - Passed internal smoke tests
>>>>> - JTreg test: http://cr.openjdk.java.net/~zgu/6995781/JTreport/
>>>>>
>>>>>
>>>>> Additional notes:
>>>>> - Some classes' new operators are marked _NOINLINE_ (for the same
>>>>> purpose as above), the performance runs, I performed, indicate that
>>>>> they do not impact performance numbers.
>>>>>
>>>>> - SA agent changes are in progress
>>>>>
>>>>> Thanks,
>>>>>
>>>>> -Zhengyu
>>>>>
>>>>>
>>>>>
>>>>>