- System requirements
- Profiler architecture
- Running the profiler
- Profiler activation
- Start profiling
- Solving performance problems
- CPU profiling
- Threads
- Deadlock detector
- Memory profiling
- Memory telemetry
- Memory snapshot
- Object allocation recording
- Shallow and retained sizes
- Memory views
- Memory inspections
- Comparing memory snapshots
- Support of HPROF format snapshots
- Support of Java Flight Recorder (JFR)
- Support of Portable Heap Dumps (.phd)
- Values of primitive types
- Persistent object IDs
- Useful actions
- Set description language
- Garbage collection
- Monitor profiling
- Exception profiling
- Probes: monitor events of various kinds
- Performance Charts
- Inspections: automatic recognition of typical problems
- Automatically trigger actions on event
- Summary, snapshot annotation, automatic deobfuscation
- Time measurement (CPU time, wall time)
- Filters
- Snapshot directory customization
- Export of profiling results to HTML, CSV, XML, plain text
- Profiler Java API
- Profiler HTTP API
- Command line tool to control profiling
- Settings
- FAQ: How to profile in my scenario?
Support of Portable Heap Dumps (.phd)
Eclipse OpenJ9 JVM, previously known as IBM J9 or simply IBM Java,
has a built-in feature for dumping Java heap to a file in the Portable Heap Dump (PHD)
binary format.
The associated file name extension is .phd.
You can analyze these dumps by using the powerful features that YourKit Java Profiler provides for its own memory snapshots. However, due to the PHD format limitations, not all features are available.
Format limitations
A Java heap dump in the PHD format has a number of limitations comparing with
the profiler format snapshot (.snapshot)
and a HotSpot JVM's HPROF dump (.hprof).
-
Only live objects are reported.
Reachability scopes are therefore restricted.
-
GC roots are not specified.
It is not explicitly known which objects are roots and of what kind. The profiler has to infer the root objects by using the following rules:
-
A class (i.e. instance of
java.lang.Class) loaded by the system loader becomes a roots of type "Class". - An object having no incoming references from other objects (i.e. self-references don't count) becomes a root of type "Held by JVM".
-
A class (i.e. instance of
-
No primitive type values are available in fields and arrays.
Primitive arrays like
int[]orchar[]themselves exist but their elements are unknown.Object primitive fields are not presented at all.
java.lang.Stringvalues are also unavailable because they depend on the underlying field of typechar[]orbyte[]. -
Class metadata does not include field names.
All instance field and static references are anonymous.
-
Null references are not reported for object fields and arrays.
As the result:
-
For an array with
nullelements, all reported elements are moved towards the start of the array, so the indices may differ from the original ones. However, the element order is preserved. -
For an object with
nullinstance fields, the shown reference index for the same original field may differ for different objects of the same class. The same reference number in several instances of a class does not necessarily mean the reference belongs to the same original field.
-
For an array with
Therefore, to analyse full information about the Java heap it's recommended to use a YourKit Java Profiler snapshot instead of a PHD whenever possible. Using a PHD dump makes sense when it is not possible or not feasible to capture a YourKit Java Profiler snapshot instead, e.g. when analyzing a dump automatically captured on a production machine.
Dump creation
The heap dump dump can be generated in either of two ways:
- Explicit generation
- JVM triggered generation
Explicit generation
The Java heap dump can be explicitly generated in the following ways:
-
By using the IBM/OpenJ9 Java's
jcmdcommand line utility:jcmd <PID> Dump.heapCreates file
heapdump.<date>.<time>.<PID>.<running number>.phdin the location described in Location of the heap dump.jcmd <PID> Dump.heap <path>.phdCreates file with given path.
Important: ensure that the target file does not exist at the moment of issuing the command. Otherwise, the dump command rejects to overwrite an existing file and fails with an error, e.g:
Error: openj9.management.internal.InvalidDumpOptionExceptionBase
Error in dump options. -
By sending a signal to the JVM from the operating system.
For Linux and AIX, send the JVM the signal
SIGQUIT(kill -3, orCTRL+\in the console window).For Windows, generate a
SIGINT(Ctrl+Break).To enable signal-based Java Heap dumps, the
IBM_HEAPDUMP=TRUEenvironmental variable or the appropriateJAVA_DUMP_OPTSmust be set. -
By using the
HeapDump()method inside Java code that is being executed.
Please refer to IBM Java/OpenJ9 documentation for more information.
JVM triggered generation
The following events automatically trigger the JVM to produce a Java Heap dump:
- A fatal native exception occurs in the JVM (not a Java Exception).
- An OutOfMemoryError or heap exhaustion condition occurs (optional).
If Java Heap dumps are enabled, they are normally produced immediately before a thread dump. They are produced also if the JVM terminates unexpectedly (a crash).
Please refer to IBM Java/OpenJ9 documentation for more information.
Location of the heap dump
The JVM checks each of the following locations for existence and write-permission, then stores the Heap dump in the first one that is available.
- The location that is specified by the
IBM_HEAPDUMPDIRenvironment variable, if set. - The current working directory of the JVM process.
- The location that is specified by the
TMPDIRenvironment variable, if set. - The temporary directory.