Code review request: CR 6995781 Native Memory Tracking Phase 1

[Coleen Phillmore]

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
>>>>
>>>>
>>>>
>>>>