Summary

Non-Goals

It is not a goal of this effort to reduce memory consumption or improve
performance, or to make summary tracking the default.

Success Metrics

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.

Motivation

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.

Description

This project is focused on solving the bottlenecks in the current native
memory tracking implementation, especially the memory and CPU overheads
on tracking malloc activities.

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 malloc
allocation sites; this data structure further reduces the memory overhead
for malloc detail tracking and query time. It also avoids blocking
calls on regular JVM execution paths while tracking malloc activities,
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.

Testing

Current native memory tracking tests should cover the basic/functionality
tests. New scalability tests may be needed.