Code review request: CR 6995781 Native Memory Tracking Phase 1

[Zhengyu Gu]

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