Java Garbage Collector
Java Garbage Collection Types and Settings
Garbage Collection (GC) is Java’s automatic memory-management mechanism. It identifies objects that are no longer needed and releases their memory for reuse, helping Java applications use container RAM more efficiently.
Java Garbage Collection Overview
Every Java object consumes heap memory while it is referenced by the running application. When no references remain, the object can be considered unused and its memory becomes eligible for reclamation by the garbage collector.
The choice of collector affects pause times, throughput, CPU usage and how efficiently the JVM returns unused memory. In elastic cloud environments this behavior also influences how well Java applications work with automatic vertical scaling.
Supported Garbage Collectors
-XX:+UseG1GC — server-oriented collector that divides the heap into regions and prioritizes collection in regions with less live data. It is the default collector for modern Java versions in the platform.-XX:+UseShenandoahGC — concurrent collector designed to keep stop-the-world pauses very short across both small and large heaps.-XX:+UseZGC — scalable, low-latency collector intended for applications with large heaps and strict response-time requirements.-XX:+UseEpsilonGC — passive collector that allocates memory but does not reclaim unused objects. Useful mainly for testing, memory analysis and performance measurement.-XX:+UseParNewGC — multithreaded young-generation collector with stop-the-world phases and memory compaction.-XX:+UseParallelGC — parallel young-generation collection focused on throughput.-XX:+UseParallelOldGC — parallel mark-and-compact collection for the old generation.-XX:+UseConcMarkSweepGC — collector designed to reduce pause times by performing part of the work concurrently with application threads.-XX:+UseSerialGC — single-threaded collector with low memory overhead but potentially longer pauses.OpenJ9 uses different options
OpenJ9 does not use the collector flags listed above. Its JVM provides its own idle-tuning options and garbage-collection behavior.
Default JVM and GC Settings
For Java 8 and newer JVMs, G1 GC is used by default. Older JVM releases can use ParNew GC. Legacy JVMs may also rely on an additional GC agent to support automatic vertical memory scaling.
For newer Java releases, periodic G1 collection can be coordinated with container load through predefined variables.
Java process settings can be checked from SSH with:
ps -ax | grep java
The platform also calculates several heap parameters automatically based on the amount of RAM available to the Java container.
Customize Garbage Collection Settings
Default values can be changed when an application has specific latency, memory or throughput requirements. Such tuning should be performed only when the impact of the chosen GC and heap parameters is well understood.
GC options can be provided through environment variables or through the Java server’s variables.conf file.
_JAVA_OPTIONS="-XX:+UseShenandoahGC"
Test before production
Benchmark any custom collector and heap configuration under realistic application load before enabling it for production traffic.
GC and Heap Configuration Variables
| Variable | Purpose | Example |
|---|---|---|
| _JAVA_OPTIONS | Pass JVM options, including a custom garbage collector. | -XX:+UseShenandoahGC |
| JAVA_TOOL_OPTIONS | Alternative JVM option injection mechanism. | Custom JVM flags |
| GC_DEF | Defines the garbage collector type. | G1GC |
| XMX_DEF_PERCENT | Percentage of RAM assigned to the maximum heap. | 80 |
| XMX_DEF / XMX | Maximum Java heap size. | 1638M |
| XMS_DEF / XMS | Initial heap size. | 32M |
| XMN_DEF | Young-generation heap size. | 30M |
| G1PERIODIC_GC_INTERVAL | Frequency of G1 periodic collection. | 900 |
| G1PERIODIC_GC_SYS_LOAD_THRESHOLD | System-load threshold for G1 periodic collection. | Calculated or custom value |
| GC_SYS_LOAD_THRESHOLD_RATE | Multiplier used in load-threshold calculation. | 0.3 |
| FULL_GC_AGENT_DEBUG | Enables or disables debug logging for GC processes. | true |
| FULL_GC_PERIOD | Interval between full-GC calls. | 900 |
| XMINF_DEF | Controls minimum free heap space before heap expansion. | 0.1 |
| XMAXF_DEF | Controls when the JVM compacts an excessively free heap. | 0.3 |
Java Server Configuration Paths
| Java Server | variables.conf Path |
|---|---|
| Tomcat / TomEE | /opt/tomcat/conf/variables.conf |
| GlassFish | /opt/glassfish/glassfish/domains/domain1/config/variables.conf |
| Spring Boot | /home/jelastic/conf/variables.conf |
| WildFly | /opt/wildfly/conf/variables.conf |
| Payara | /opt/payara/glassfish/domains/domain1/config/variables.conf |
| Java Engine | /home/jelastic/conf/variables.conf |
| Jetty | /opt/jetty/etc/variables.conf or the shared configuration path |
Example: Replace G1 with Shenandoah GC
- Open the configuration files for the Java server.
- Navigate to the appropriate
variables.conffile. - Add the custom garbage-collector flag.
-XX:+UseShenandoahGC
After the server restarts, the explicitly configured collector is used instead of the default G1 collector.
Monitor Garbage Collection
After applying the required options, monitor the Java container through the Statistics section and review JVM behavior under real application load.
Important Notes
- G1 GC is the default collector for modern Java versions in the platform.
- Choose a custom collector only when the application’s latency, throughput or heap characteristics justify the change.
- Do not confuse platform environment variables with raw Java options.
- Heap settings and GC behavior should be tested together with automatic vertical scaling.
- OpenJ9 uses its own tuning options rather than the standard GC flags listed above.
- Configuration paths vary depending on the selected Java application server.