KB – JVM Tuning: Less Can be More

Understanding the Java Virtual Machine (JVM) Garbage Collection

Under the hood, BBj is a Java application.  One of the most significant benefits of Java is automatic memory management. Unlike languages like C or C++, where programmers manually handle memory cleanup, Java’s garbage collector (GC) takes care of this automatically. Objects created in your code reside on the heap until they are no longer referenced. When an object becomes unreachable, the GC removes it from memory, making room for new objects.

The Importance of Garbage Collection (GC) Tuning

Garbage collection isn’t free—it consumes resources. While the JVM handles memory cleanup, it does so at the expense of CPU cycles. Instead of focusing solely on business logic, the CPU may spend time managing unused data. Efficient garbage collection is crucial to ensure that the application runs smoothly. Fortunately for the Java community, major new versions of Java most often incorporate improved or new versions of the Garbage Collection algorithm, often requiring little to no GC tuning. 

A Common Misconception: More Memory Is Better

At first glance, it seems logical to allocate as much memory as possible for the max heap. After all, more memory should lead to better performance, right? However, this intuition can be misleading.

JVM garbage collectors are greedy.  The collectors tend to consume large portions of the heap before starting collections.  In some cases over time most of the heap will be used but filled with objects that should be collected.  If a full GC is started when most of a very large heap is filled with collectable objects it can take a very long time for the full GC to complete.  We have seen Full GCs take up to an hour with max heaps set at 60GB or higher.

Don’t touch that dial!  Way back in 2010, Oracle Java introduced a ‘zero setting’ option that dynamically allocates memory to Java applications, based on the hardware profile of the client/server and the memory needs of the application.  In the vast majority of BBj deployments, it is not necessary to set an explicit max heap (-Xmx) or starting heap (-Xms).   

The 32 GB Line  Generally speaking, BASIS *never recommends going above 31GB for the max heap.  At the 32GB(-Xmx32g) point, Java uses 64-bit pointers instead of 32-bit pointers, so you have effectively dropped your max heap to 24GB (perhaps lower, depending upon the number of objects).

* In some very rare cases, it may be necessary to increase the heap above 32g.  In such cases, BASIS recommends setting the max heap(-Xmx) to 44g or 48g.   This is because a 44g to 48g heap stores about the same amount of data as a 31g heap.  Again, this is true since the JVM has to use 64 bit pointers instead of 32 bit pointers once the heap size reaches 32g.  Please consult BASIS support before increasing your heap size beyond 31g.

Summary

In the realm of Java applications, memory management is a critical aspect. The garbage collector (GC) dutifully handles memory cleanup, ensuring that objects no longer in use are promptly removed from the heap. However, fine-tuning garbage collection is essential to strike a balance between memory efficiency and CPU utilization.

Beware of Greedy Collectors: JVM garbage collectors can be voracious. They tend to consume significant portions of the heap before initiating collections. Over time, the heap may fill with objects that should be collected, leading to prolonged full GC cycles. We’ve witnessed full GCs lasting up to an hour on massive heaps exceeding 60GB.

Out of the box settings:  In most cases, Java’s ‘zero setting’ is the correct setting. Don’t touch that dial!

The 32GB Threshold: BASIS advises against exceeding a 31GB max heap. Beyond this point (specifically at -Xmx32g), Java switches to 64-bit pointers.  Effectively, reducing the max heap setting from 32g to 31g will increase the heap size by 6g or so.

Rare Exceptions: While it’s uncommon, there might be scenarios where increasing the heap beyond 32GB becomes necessary. In such cases, it’s best to consult BASIS engineering before making this change.

Remember, when it comes to memory allocation, sometimes less truly is more. Striking the right balance ensures optimal performance without sacrificing precious CPU cycles.