Code review request: CR 6995781 Native Memory Tracking Phase 1

[Thomas Stüfe]

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