Objects are created in the memory to service incoming requests. Once requests are serviced, newly created objects will become useless (i.e. garbage). This garbage must be evicted from the memory so that there is enough room created in the memory to service the new incoming requests. If there isn’t sufficient memory, the application can experience poor response times, OutOfMemoryError, and fatal crashes.
In Java, Android, C# etc., garbage collection is automatic, whereas in the several predecessor programming languages (C, C++) the programmer must write code explicitly to release the objects after they are used. So, it’s a major convenience for Java, Android, and C# application developers. But this automatic garbage collection is not free, it comes with a price. Automatic Garbage Collection can have a profound impact on:
- Application Response Time
Application Response Time
To garbage collect objects automatically, the entire application has to be paused intermittently to mark the objects that are in use and sweep away the objects that are not used. During this pause period, all customer transactions which are in motion in the application will be stalled (i.e. frozen). Depending on the type of GC algorithm and memory settings that you configure, pause times can run from a few milliseconds to a few seconds to a few minutes. Thus, Garbage Collection can affect your application SLA (Service Level Agreement) significantly.
Garbage collection consumes a lot of CPU cycles. Each application will have thousands/millions of objects sitting in memory. Each object in memory should be investigated periodically to see whether they are in use. If it’s in use, who is referencing it? Are those references still active? If they are not in use, they should be evicted from memory. All these investigations and computation requires a considerable amount of CPU power.
Of course, poor GC configuration can lead to high memory consumption and vice versa. Most applications saturate memory first before saturating other resources (CPU, network bandwidth, storage). Most applications upgrade their EC2 instance size to get additional memory rather than getting additional CPUs or network bandwidth.
Thus, to have top-notch SLAs and reduce the bill from your cloud hosting provider, your application's garbage collection has to function effectively. In order to study and optimize garbage collection's impact on an application’s performance, one has to enable Garbage Collection Logging. Besides that, garbage collection logs can be used to troubleshoot memory-related problems in the application.
Enabling GC Logs
GC Logging can be enabled by passing in the below-mentioned system properties during application startup.
Until Java 8:
Below is the system property that is supported by all versions of Java until JDK 8.
-XX:+PrintGCDetails -Xloggc:<gc-log-file-path> Example: -XX:+PrintGCDetails -Xloggc:/opt/tmp/myapp-gc.log
From Java 9:
Below is the system property that is supported by all versions of Java starting with JDK 9.
-Xlog:gc*:file=<gc-log-file-path> Example: -Xlog:gc*:file=/opt/tmp/myapp-gc.log
How to Analyze GC Logs
Here is a sample GC log generated when the above system properties were passed:
A GC log has rich information, however, understanding GC logs is not easy. There isn’t sufficient documentation to explain GC log format. On top of that, GC log format is not standardized. It varies by JVM vendor (Oracle, IBM, HP, Azul, …), Java version (1.4, 5, 6, 7, 8, 9), GC algorithm (Serial, Parallel, CMS, G1, Shenandoah), GC system properties that you pass (-XX:+PrintGC, -XX:+PrintGCDetails, -XX:+PrintGCDateStamps, -XX:+PrintHeapAtGC …). Based on this permutation and combination, there are easily 60+ different GC log formats.
Thus, to analyze GC logs, it’s highly recommended to use GC log analysis tools such as GCeasy, HPJmeter. These tools parse GC logs and generate great graphical visualizations of data, reports Key Performance Indicators and several other useful metrics.
Here is a sample GC log analysis report generated by the GCeasy tool.