Java Reference
In-Depth Information
DETAILED MEMORY TRACKING INFORMATION
If the JVM is started with -XX:NativeMemoryTracking=detail , then jcmd (with a final detail
argument) will provide very detailed information about the native memory allocation. That in-
cludes a map of the entire memory space, which includes lines like this:
0x00000006c0000000 - 0x00000007c0000000] reserved 4194304KB for Java Heap
from [ReservedSpace::initialize(unsigned long, unsigned long,
bool, char*, unsigned long, bool)+0xc2]
[0x00000006c0000000 - 0x00000006fb100000] committed 967680KB
from [PSVirtualSpace::expand_by(unsigned long)+0x53]
[0x000000076ab00000 - 0x00000007c0000000] committed 1397760KB
from [PSVirtualSpace::expand_by(unsigned long)+0x53]
The 4 GB of heap space was reserved in the initialize() function, with two allocations from
that actually made in the expand_by() function.
That kind of information is repeated for the entire process space. It provides really interesting
clues if you are a JVM engineer, but for the rest of us, the summary information is useful enough.
NMT provides two keys pieces of information:
Total committed size
The total committed size of the process is the actual amount of physical memory that the
process will consume. This is close to the RSS (or working set) of the application, but
those OS-provided measurements don't include any memory that has been committed but
paged out of the process. In fact, if the RSS of the process is less than the committed
memory, that is often an indication that the OS is having difficulty fitting all of the JVM
in physical memory.
Individual committed sizes
When it is time to tune maximum values—of the heap, the code cache, and the
metaspace—it is helpful to know how much of that memory the JVM is actually using.
Overallocating those areas usually leads only to harmless memory reservations, though in
those cases where the reserved memory is important, NMT can help to track down where
those maximum sizes can be trimmed.
Search WWH ::




Custom Search