GC logging provides valuable insights for diagnosing memory issues and tuning Java-based application performance. Some Java users believe enabling garbage collection logging will have a significant impact on their performance metrics, but the impact can actually be quite minimal. Learn how Azul’s C4 Collector makes garbage collection logging easier, safer, and more insightful, without impacting performance.
The Java Garbage Collector (GC) is a critical part of the Java Virtual Machine (JVM). It controls how memory is used and automatically frees the memory space consumed by objects that are no longer used. When objects stored in memory have become “unreachable” for the program, the GC detects them and cleans them up.
With every collection event, a GC log reveals key details about how much memory is being used and reclaimed, how long it’s taking, and whether your JVM had to pause your application.
Some Java developers think logging will create additional overhead, consume disk space, or introduce latency during peak traffic. Those concerns are often valid, especially in performance-critical environments.
But Azul Platform Prime includes Azul Zing, an award-winning enhanced build of OpenJDK. With Prime, you can unlock the full benefits of GC logs at scale with minimal cost.
Common GC logging risks (and how Azul handles them)
When GC logging is enabled, every time the JVM performs a garbage collection, it stores information in a log file.
Category | Details |
---|---|
Type of GC event | Minor GC: Cleans the young generation space Major GC: Cleans the old generation space Full GC: Cleans the entire heap space |
Time | When the GC event started |
Duration | How long the GC event lasted |
Amount of memory | Memory used before and after the GC event for each memory pool |
Total available memory | Total memory available in each pool |
Enabling GC logging in a Java application generally has minimal performance impact, especially with modern JVMs. However, the exact impact may vary based on the JVM version, the GC algorithm used, and other settings and details. These are a few facts you’ll need to take into consideration:
- Avoid filling a file system: By default, Java 9 and newer versions have log file rotation enabled and will only write five log fragments of 20MB each.
- Limit I/O operations: JC logs are written directly to the disk. This creates I/O operations and can slow down the application if the disk is slow or there’s a high percentage of disk usage.
- Memory buffering: Modern JVMs typically use a memory buffer for GC logs. When the buffer is full, the logs go to disk to reduce the I/O impact. The buffer takes up memory that the application could use otherwise.
- Watch detailed GC logs: You may notice a performance impact if detailed GC logs are enabled, since recording and processing this data consumes CPU resources.
- Enjoy safe points: All GC logging activity happens at “safe points” in the application’s execution, where it doesn’t cause more “stop the world” pauses than would occur due to regular GC activity.
However, not all JVMs are created equal. Azul Zing takes GC logging to another level, giving developers deeper insights and greater control with less tuning and overhead.
GC logging, the Azul way
Azul Platform Prime makes GC logging simpler, smarter, and safer.
Unlike OpenJDK-based runtimes, which often require additional flags like gc* or safepoint to get the full picture, Zing automatically includes the most useful performance data with a single flag:
-Xlog:gc:gc.log
Zing logs go further by including:
- Safepoint activity: Even with the basic gc flag, Zing includes all GC pauses and safepoint information.
- JIT compiler behavior: Helps diagnose warmup delays or inefficient compilation paths.
- System metrics: Includes CPU and memory utilization, Linux page cache stats, and process-level insights.
- Container and process context: Makes it easier to correlate environment changes with GC behavior.
- Off-heap memory info: A must-have for diagnosing out-of-memory issues in complex systems.
This extra context can help developers solve problems faster, reduce tuning guesswork, and eliminate costly trial-and-error in performance troubleshooting.
Eliminate GC pauses with C4
Zing is the award-winning enhanced build of OpenJDK that is included in Azul Platform Prime. Based on OpenJDK, Zing is TCK-verified and delivers superior application performance, responsiveness, and efficiency. It always logs safepoint pauses and even additional information not seen in OpenJDK GC logs by default, like just-in-time (JIT) compiler activity, CPU and memory usage, Linux page cache metrics, and a few more metrics often relevant for system performance analysis.
Compared to standard OpenJDK runtimes, GC logs produced by the Zing JVM provide a wide variety of additional information.
- General System Info is useful for validating the setup and other configurations, including the GC log.
- Java Heap Info contains detailed information about garbage collection and memory management.
- Off-Heap Memory Info looks at the memory allocated outside the Java heap and helps diagnose out-of-memory errors and general memory consumption.
- Process, Container and System Info collects ongoing information about the environment that the JVM is running in, great for health and correlating the environment with other logged application activity.
- JIT Compiler Info provides detailed information about the JIT compiler, including JVM warmup behavior and when the JVM is ready to make traffic.
Real results: from insight to impact
Azul customers have put Zing with the C4 Collector to work at scale, and the outcomes speak for themselves.
![]() LMAX ran 48% faster than other Java runtimes and improved their order fill ratio by eliminating GC-induced slowdowns. View case study |
Workday reclaimed 42,000 person-hours across 18 months that would have been spent on GC performance tuning and troubleshooting. View case study |
![]() BIDS dramatically improved performance and introduced a 95% reduction in effort on GC tuning and workarounds over one year. View case study |
![]() Mastercard eliminated more than 10,000 garbage collection pauses per day for systems that identify fraud in microseconds at high volumes. |
Tools to take you further
With GC logs in place, Azul provides rich tooling to help make sense of the data:
- Azul GC Log Analyzer: A graphical tool that turns logs into charts, timelines, and trends, covering GC activity, JIT behavior, system stats, and more.
- jstat and VisualVM: Standard tools that complement Zing logs for cross-validation and real-time monitoring.
- Documentation and support: Azul’s GC logging docs include format breakdowns and best practices to get the most out of every byte logged.
Get better insights without tradeoffs
If you’ve hesitated to enable Java GC logging in production, now’s the time to reconsider. With Azul Zing and the C4 collector in Platform Prime, you get all the insight with none of the disruption. More data, fewer pauses, and no extra tuning.
Whether you’re troubleshooting an incident, diagnosing memory leaks, or tuning for performance, GC logs are essential—and Azul makes them effortless.
Ready to dive deeper into your JVM performance?