Java Garbage Collection in Jelastic Cloud

Performance and price are two big considerations in application hosting that always matter. And the question is how to decrease dollars spent, without affecting the performance of your apps at the same time. This document is devoted to automatic memory management for Java applications hosted with Jelastic using Garbage Collection.

Java Garbage Collection Overview

Garbage Collection (GC) 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.


Jelastic Default GC Settings

If no custom GC is specified, Jelastic will configure it as follows:
  • ParNew for all servers with resource limits below 8GB
  • G1 for servers with resource limits above 8GB (64 cloudlets and more)

In this case, it doesn’t matter how many cloudlets are actively consumed. Garbage Collector takes into consideration a Scaling Limit - the maximum amount of cloudlets that you set for each server.

Scaling limit scheme

ParNew Garbage Collector

ParNew is a "stop-the-world" multi-threaded Garbage Collector. It collects the young generation of objects. Since the young generation is normally small in size, in Jelastic this ParNew collector is used only for servers with resource limits below 8GB. Based on the size, the collection is very fast and does not impact your application too much. In addition, ParNew collector has a compaction of unused RAM that enables support of automatic vertical scaling - one of the prominent Jelastic features.

Garbage-First Garbage Collector

The Garbage-First (G1) collector is a server-style Garbage Collector for multi-processor machines with large memories. 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.

G1 is focused on applications that require large heaps with limited GC latency. After deep analysis, we reached the conclusion that 8GB of RAM consumption is big enough for using G1.

Together with these settings, a special Jelastic GC agent is used to release unused RAM by JVM to OS.