Performance and price are two big considerations in application hosting that always matter. And, often, we question ourselves on how to decrease the spends, without affecting the performance of your apps at the same time. In this article, we'd like to address automatic memory management for Java applications hosted with Jelastic using garbage collection.

Let's clarify what garbage collection is, what it does for Java applications, and how it works within Jelastic PaaS.

Java Garbage Collection Overview

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.

Jelastic supports the following GCs:

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 Jelastic 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.

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 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.

G1PERIODIC_GC_SYS_LOAD_THRESHOLD={CPU_cores_number}*GC_SYS_LOAD_THRESHOLD_RATE Activates garbage collection if the average one-minute system load is below the set value. This condition is ignored if set as zero.

You can always check current settings of your Java process by executing ps -ax | grep java. You will see something like this:

Customization of GC Settings in Jelastic PaaS

If you believe that customization of default settings can improve performance or memory consumption, you can tune them according to the requirements of your application. We recommend customizing these configurations only if you fully understand the impact of such changes on your application behavior.

_JAVA_OPTIONS and JAVA_TOOL_OPTIONS — please read more about these options. .Java options can be used for changing default GC type, for example _JAVA_OPTIONS="-XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC"

GC_DEF – a type of Garbage Collector, for example, GC_DEF=G1GC

XMX_DEF_PERCENT – RAM percentage to be provided as XMX, for example, XMX_DEF_PERCENT=80

XMX_DEF (or just XMX) – the maximum size for the Java heap memory, for example, if total RAM is 2048Mb, the XMX_DEF=1638

G1PERIODIC_GC_SYS_LOAD_THRESHOLD (for OpenJDK 12/13 only) – allows G1 Periodic Collection execution, if the average one-minute system load is below the set value. This condition is ignored if set as zero. By default, it is equal to the {CPU_cores_number}*{GC_SYS_LOAD_THRESHOLD_RATE}

MAXPERMSIZE — automatically defined only for those Java containers, which run JVM version lower than 8th and with an allocated amount of RAM>. In all other cases (i.e. if container scaling limit is less than 7 or it uses Java 8), this parameter is omitted. The actual value of theMaxPermSizesetting is calculated based on memory amount divided by ten but cannot be set greater than the maximum of 256 MiB. For example, MAXPERMSIZE=163.

XMINF_DEF — this parameter controls the minimum free space in the heap and instructs the JVM to expand the heap, if after performing garbage collection, it does not have at least an XMINF_DEF value of free space. For example, XMINF_DEF=0.1

XMAXF_DEF — this parameter controls how the heap is expanded and instructs the JVM to compact the heap if the amount of free space exceeds XMAXF_DEF value. For example, XMAXF_DEF=0.3

Alternatively, all these parameters can be passed to Java process via variables.conf in the container.

All of the paths to config, executable, or log files can differ based on the Java server you use and can be accessed via Configuration File Manager or SSH.

In the opened variables.conf file, you can override the garbage collector default settings or even add another GC to replace the default one (G1). So if you want to use ShenandoahGC instead, simply add it to the variables.conf, as stated in the example below:

-XX:+UnlockExperimentalVMOptions

-XX:+UseShenandoahGC

After this, only the specified garbage collector will be used while starting your Java server without taking into consideration the number of allocated resources.

Also, you can control how JVM handles its heap memory with other Java options stated in this file.

As a result of properly configured options, the GC can be observed in action via the Statistics tab.