- 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?
Memory telemetry
After you are connected to the profiled application, find the Memory tab on the session panel.
Memory profiling controls in the toolbar
| Toolbar Button | Description |
|
Capture memory snapshot - save the profiling results to a file for comprehensive analysis |
|
Start/stop object allocation recording |
|
Reset recorded object allocations and continue recording |
|
Explicitly run garbage collector in the profiled application |
Memory usage graphs
Memory tab's section Memory & GC Telemetry shows the following graphs:
-
Heap Memory shows Java heap statistics. Java uses the heap as the storage for Java objects. You can see individual pools or all pools together.
-
Non-Heap Memory shows the non-heap memory statistics. Java uses the non-heap memory to store loaded classes and other metadata. You can see individual pools or all pools together.
-
Classes shows how the number of loaded classes changed in time, and the total number of unloaded classes.
-
Garbage Collection and Time Spent in GC show the garbage collection statistics (read more)
-
Object Allocation Recording graph shows the number of objects created per second. Please note that this graph is populated only when object allocation recording is running. To get the results with minimum overhead please use the object counting mode.
The telemetry information is remembered in a circular buffer in the profiler agent memory. This allows you to connect to a profiled application on demand and discover how the application behaved in the past.
The buffer capacity is 1 hour by default, and can be changed with the startup option
telemetrylimit.
Class instance count telemetry
Classes view shows object counts by class. It is located in the Memory & GC Telemetry section of the Memory tab.
This view is available when the profiler is connected to a running application, allowing to instantly learn object counts without capturing and opening a memory snapshot.
This view is also available in performance snapshots, but is not available in memory snapshots being superseded with objects view.
The presented information can be useful as an overview of memory consumed by the profiled application and also as a clue to detecting memory leaks. For details, see How to find out why application eats that much memory? and How to find memory leaks?
This view, unlike other telemetry views, does not automatically periodically update. This is for performance considerations: gathering the statistics may take significant time in case of huge heaps with many objects, thus should run on demand.
Instead, it updates when:
- Refresh button is pressed when the tab is visible (an explicit update)
- Force Garbage Collector button is pressed when the tab is visible (it makes sense to immediately see the changes in object counts and sizes after forcing garbage collection)
- a snapshot is captured (gathering the statistics is a part of the capture)
Allocation telemetry
You can profile object allocation without capturing a memory snapshot.
Memory tab's section Allocations shows counts and sizes for objects whose allocations have been recorded, including objects which are still alive as well as objects that have been collected by the moment.
This live view provides only basic information, and you still need to capture memory snapshot to perform comprehensive analysis: to separate live objects from dead objects, to see where live objects are retained, etc.