Garbage Collection is a form of automatic memory management. Its aim is to find data objects in memory that are no longer demanded and make their space available for reuse.

The created object uses some memory that remains allocated until there are references for the use of the object. When there are no references for an object, it is considered to be no longer required and the memory occupied by the object can be reclaimed. In such a way, you don’t pay for unused resources and can cut your costs.

We’ve tested different kinds of Garbage Collectors (GC) and defined the most appropriate ones for the Java applications hosted in our cloud, taking into consideration the automatic vertical scaling that CirrusGrid provides. As a result of our investigations, we adjusted the default settings of Garbage Collectors in CirrusGrid in order to increase the benefits for our users.

CirrusGrid supports the following GCs:

• G1 GC (-XX:+UseG1GC) is a default GC in CirrusGrid PaaS. The Garbage-First (G1) is a server-style Garbage Collector for multiprocessor machines with a large amount of memory. The heap is partitioned into fixed-sized regions and G1 tracks the live data in those regions. When Garbage Collection is required, it collects from the regions with less live data first.

• Shenandoah GC (-XX:+UseShenandoahGC) is a concurrent garbage collector for the JVM. Concurrent means that the GC tries to perform most of the activities in parallel without interrupting application performance. Such parallelism makes “stop-the-world” (STW) pauses extremely short that is the most required task for each GC. Another inherent advantage is an efficient work with small and large heaps with no impact on STW pauses’ length. The Shenandoah GC uses an additional -XX:ShenandoahGCHeuristics=compact option.

• ZGC (-XX:+UseZGC) is low latency scalable garbage collector. Designed for use with applications that require a large heap and low latency. It uses a bunch of one generation and performs most (but not all) garbage collection in parallel with uninterrupted application work. This greatly limits the impact of garbage collection on your application response time. The ZGC uses an additional -XX:ZCollectionInterval=$ZCOLLECTION_INTERVAL option to set the maximum interval (in seconds) between two GC cycles (can be redefined via the ZCOLLECTION_INTERVAL variable).

• Epsilon GC (-XX:+UseEpsilonGC) is a passive GC that handles memory allocation and doesn’t clear it when objects are no longer used. When your application exhausts the Java heap, the JVM goes down. So, EpsilonGC prolongs an application life until the memory will run out and dumps the memory, that can be useful for application memory usage debugging, as well as measuring and managing application performance.

• Parallel
  • ParNew GC (-XX:+UseParNewGC) is a “stop-the-world” multithreaded Garbage Collector. Mostly it is aimed to collect the young generation objects. Since the young generation is normally small in size, the ParNew does collection very fast and does not impact your application too much. In addition, ParNew has compaction of unused RAM that enables support of automatic vertical scaling – one of the prominent CirrusGrid features.
  • Parallel GC (-XX:+UseParallelGC) is used when the parallel collection method  is required over young generation only. It cannot be applied along with ConcMarkSweep GC simultaneously unlike ParNew GC.
    
  • Parallel Old GC (-XX:+UseParallelOldGC) utilizes a parallel “mark and compact” algorithm which catches all application threads and then handles labeling and subsequent compaction with multiple garbage collector threads.
• ConcMarkSweep GC (-XX:+UseConcMarkSweepGC) collector is designed for applications that prefer shorter garbage collection pauses and which can afford to share processor resources with the garbage collector while the application is running. It makes sense to use such a collector when applications requirements for time garbage collection pauses are low.
• Serial GC (-XX:+UseSerialGC) performs garbage collection in a single thread and has the lowest consumption of memory among all GC types but, at the same time, it makes long pauses that can lead to application performance degradation.