Improve the scalability of native memory tracking.
We do not intend to add any new functionality.
It is not a goal of this effort to reduce memory consumption or improve performance, or to make summary tracking the default.
Native memory tracking can be run without self-shutdown on large systems without causing a significant performance impact beyond what is currently considered acceptable for small projects.
The Native Memory Tracking feature is designed to help diagnose VM memory
leaks as well as to clarify for users when memory leaks are not in the
VM. The current implementation tends to perform poorly on large systems,
when there are a large number of
malloc calls in a short period. It
not only consumes significant amounts of memory for tracking, but also
CPU cycles to process the tracking data.
This project is focused on solving the bottlenecks in the current native
memory tracking implementation, especially the memory and CPU overheads
The new approach eliminates
malloc tracking records by co-locating
tracking data along with
malloc'd memory, which not only reduces the
memory for the tracking data but also avoids the processing of raw
tracking data. A lock-free hash table is used to track
allocation sites; this data structure further reduces the memory overhead
malloc detail tracking and query time. It also avoids blocking
calls on regular JVM execution paths while tracking
which should also reduce the impact to JVM performance.
The new implementation co-locates the
malloc tracking header with user
data, it ensures that user data aligns with
malloc alignment in a
production build (8 bytes on 32-bit systems and 16 bytes on 64-bit
systems), and 8-byte alignment on debug build.
Current native memory tracking tests should cover the basic/functionality tests. New scalability tests may be needed.
- is blocked by
JDK-8061860 EP-JDK-8044192: SQE Test Plan for Scalable Native Memory Tracking
- relates to
JDK-8064740 TOI: JEP 195: Scalable Native Memory Tracking