RFR (L) 8028541: Native Memory Tracking enhancement

[Christian Tornqvist]

Hi Zhengyu,

I've only covered parts of this change so far, but here is some of my early feedback:

src/os/linux/vm/os_linux.cpp 
* Line 226 & 227, incorrect indentation

src/os/posix/vm/os_posix.cpp
* Line 80 (and other): should not have spaces between variable and ++/--

src/os/solaris/vm/os_solaris.cpp
* Line 566 & 567, incorrect indentation

src/os/windows/vm/os_windows.cpp
* Line 162 & 163, incorrect indentation

src/os/windows/vm/perfMemory_windows.cpp
* Line 1844, can you move the remove_file_mapping call outside the if statement to get rid of the else statement?

src/share/vm/memory/allocation.inline.hpp
* Incorrect indentation on many lines

src/share/vm/services/memBaseline.cpp
* Incorrect indentation on many lines
* Line 92, should not have spaces between variable and ++/--
* Line 136, Split the assert into two asserts
* aggregate_virtual_memory_allocation_sites() returns a bool but you never check the return value?
* Why don't you merge malloc_sites (and the virtual equivalents) with malloc_sites_to_size_order() and malloc_sites_to_site_order(). The code is 95% the same and you should be able to easily remove the duplicated code here.

src/share/vm/services/memBaseline.hpp
* Line 165, Split the assert into two asserts

Thanks,
Christian

-----Original Message-----
From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Zhengyu Gu
Sent: Thursday, May 22, 2014 3:19 PM
To: hotspot-dev at openjdk.java.net
Subject: RFR (L) 8028541: Native Memory Tracking enhancement

This is significant rework of native memory tracking introduced in earlier releases.

The goal of this enhancement is to improve scalability, from both tracking memory and CPU usage perspectives, so it can scale well with increased memory allocation in large applications.

The enhancement is mainly focused on malloc memory tracking, whose activities are several magnitude higher than virtual memory, and was the main bottleneck in early implementation.

Instead of using book keeping records for tracking malloc activities, new implementation co-locates tracking data along side with user data by using a prefixed header. The header size is 8 bytes on 32-bit systems and 16 bytes on 64-bit systems, which ensure that user data also align properly.

Virtual memory tracking still uses book keeping records, and ThreadCritical lock is always acquired to alter the records and related data structures.

Summary tracking data is maintained in static data structures, via atomic operations. Malloc detail tracking call stacks are maintained in a lock free hashtable.

The key improvements:
   1. Up-to-date tracking report.
   2. Detail tracking now shows multiple call frames. Number of frames is compilation time decision, currently default to 4.
   3. Malloc tracking is lock free.
   4. Tracking summary is reported in hs_err file when native memory tracking is enabled.
   5. Query is faster, uses little memory and need a very little process.

The drawback is that, malloc tracking header is always needed if native memory tracking has ever been enabled, even after tracking is shutdown.

Impacts:
   The most noticeable impact for JVM developers, is that Arena now also take memory type as constructor parameter, besides the new operators.
      Arena* a = new (mtCode) Arena()  => Arena* a = new (mtCode)
Arena(mtCode)

The webrev shows modification of about 60 files, but most of them are due to tracking API changes, mainly due to tracking stack, now, is an object, vs. a single pc.

The most important files for this implementations are:

memTracker.hpp/cpp
mallocTracker.hpp/cpp and mallocTracker.inline.hpp virtualMemoryTracker.hpp/cpp mallocSiteTable.hpp/cpp

allocationSite.hpp
nativeCallStack.hpp/cpp
linkedlist.hpp


Tests:
   - JPRT
   - NMT test suite
   - vm.quick.testlist
   - Kitchensink stability test for 16+ days
   - FMW

Bug: https://bugs.openjdk.java.net/browse/JDK-8028541
Webrev: http://cr.openjdk.java.net/~zgu/8028541/webrev.00/

Thanks,

-Zhengyu