Code review request: CR 6995781 Native Memory Tracking Phase 1

[Vladimir Kozlov]

Zhengyu Gu wrote:
> Vladimir,
> 
> I did find that compiler sometimes uses Arenas as value or stack 
> objects,  they are actually tracked through Arena::set_size_in_bytes(), 
> only they can not be categorized, so you may see "Unknown" category.
> 
> Thread resource areas are malloc'd arenas, they should already be 
> tracked. GrowableArray is tracked through c-heap allocation (c-heap 
> type), arena or resource area.

Yes, they are tracked but they are not marked as mtCompiler. So result will be 
is not as useful as it could be.

> 
> Please let me know if I missed anything, and could you point me a few 
> instances?

What about dumping memory usage info into hs_err file when VM crash?

Vladimir

> 
> Thanks,
> 
> -Zhengyu
> 
> On 6/13/2012 2:15 PM, Vladimir Kozlov wrote:
>> Zhengyu,
>>
>> You missed a lot of places in JIT compilers, c1 and opto, where we use 
>> arenas, thread resource areas, GrowableArrays. Could be because some 
>> arenas are embedded like _comp_arena. Compilers can eat several 
>> hundreds MBytes easily.
>>
>> Is it possible to implement lightweight of this to turn it ON always 
>> to dump usage info into hs_err file when VM crash? You don't need to 
>> track PC for that, only total usage by MemoryType. It would be very 
>> useful because we see a lot of OOM crashes recently (we have it in 
>> each Nightly testing).
>>
>> Thanks,
>> Vladimir
>>
>> 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
>>>
>>>
>>>
>>>