- System requirements
- Profiler architecture
- Profiler installation
- Uninstall profiler
- Running the profiler
- Profiler activation
- Welcome screen
- Start profiling
- Profiling overhead
- Snapshots
- Solving performance problems
- CPU profiling
- Thread profiling
- Virtual threads support
- Object allocation profiling
- Memory profiling
- Understanding garbage collection
- Shallow and retained sizes
- JVM memory structure
- GC roots view
- Memory tab
- Persistent object IDs
- Useful actions
- Set description language
- Monitor profiling
- Exception profiling
- Telemetry
- Probes: monitor events of various kinds
- Inspections: automatic recognition of typical problems
- Automatically trigger actions on event
- Automatic deobfuscation
- Summary
- Filters
- Profiler command line
- Export of profiling results to external formats
- Profiler Java API
- Profiler HTTP API
- Settings
- Troubleshooting and FAQ
Understanding garbage collection in Java : GC roots
What is the garbage collector roots (GC roots) in Java?
In Java, the process of automatically freeing up memory that is no longer in use is known as garbage collection (GC). The garbage collector identifies objects that are no longer needed and then reclaims the memory that was allocated to them.
The garbage collector roots (GC roots) are a set of references through which an object can be reached from the outside world. These references serve as the starting point for the garbage collector to determine if an object is reachable or not. In other words, GC roots are entry points to the graph of objects in memory. Objects that are reachable through a chain of references from GC roots are considered live objects, and those that are not are considered candidates for garbage collection.
How to inspect GC roots
YourKit Java Profiler has a special tool for inspecting GC roots, which displays all GC roots in the memory snapshot grouped by types. To view GC roots, use the Memory | GC Roots menu item.
Why are GC roots important?
1. Efficient memory management: By identifying unreachable objects, the garbage collector can reclaim memory, ensuring efficient memory utilization.
2. Preventing memory leaks: Proper identification of GC roots helps the garbage collector prevent memory leaks, which occur when objects that are no longer in use still hold onto memory.
Improved application performance: Efficient memory management leads to better application performance, as the application can avoid memory-related bottlenecks.
How to use GC roots when finding memory leaks
Memory leaks occur when objects that are no longer needed still occupy memory due to incorrect references. To find memory leaks, you can analyze the heap dump of your Java application using YourKit Java Profiler. Profiler allows you to inspect GC roots and trace the references that prevent certain objects from being garbage collected.
1. Capture memory snapshot: The first step is to capture memory snapshot of your running Java application. You can do this using YourKit Java Profiler or tools such as jmap or through Java Mission Control (JMC).
2. Analyze the memory snapshot: Load the memory snapshot into the YourKit Java Profiler, and inspect the GC roots and the object graph.
3. Identify suspected leaks: Look for objects that should not be in memory but are still being held due to references from GC roots. Check for unexpected or unnecessary references.
4. Fix and verify: Remove or update the references that cause memory leaks and verify by generating another heap dump to ensure that the leaks are resolved.
Types of GC roots
There are several types of GC roots in Java Virtual Machine:
GC root type | Description |
JNI global reference
|
Global JNI (Java Native Interface) reference. JNI references are considered GC roots. These references are typically created by native code that interacts with Java objects. |
JNI local reference
|
Local variable or parameter of JNI (Java Native Interface) method. JNI references are considered GC roots. These references are typically created by native code that interacts with Java objects. |
Local variable on stack
|
Local variables in active method frames are considered GC roots. These variables usually exist on the stack and reference objects in the heap. |
Monitor
|
Object is used as a monitor for synchronization. |
System class
|
Classes loaded by the bootstrap class loader are considered GC roots. These classes are usually part of the Java standard library and are loaded when the JVM starts. |
Thread
|
Active Java threads are considered GC roots, and running thread cannot be collected. The thread objects and their stacks may hold references to other objects via their thread local variables. |
Other
|
Object is held from garbage collection by JVM for its purposes. Actually, the list of such objects depends on JVM implementation. Possible known cases are: the system class loader, a few important exception classes which the JVM knows about, a few pre-allocated objects for exception handling, and custom class loaders when they are in the process of loading classes. |