Guide to the Most Important JVM Parameters

1. Overview

In this quick tutorial, we’ll explore the most well-known options that we can use to configure the Java Virtual Machine.

2. Explicit Heap Memory – Xms and Xmx Options

One of the most common performance-related practices is to initialize the heap memory as per the application requirements.

That’s why we should specify minimal and maximal heap size. We can use the below parameters to achieve this:

-Xms<heap size>[unit] 
-Xmx<heap size>[unit]

Here, unit denotes the unit in which we’ll initialize the memory (indicated by heap size). We can mark units as ‘g’ for GB, ‘m’ for MB, and ‘k’ for KB.

For example, if we want to assign minimum 2 GB and maximum 5 GB to JVM, we need to write:

-Xms2G -Xmx5G

Starting with Java 8, the size of Metaspace isn’t defined. Once it reaches the global limit, JVM automatically increases it. However, to overcome any unnecessary instability, we can set Metaspace size with:

-XX:MaxMetaspaceSize=<metaspace size>[unit]

Here, metaspace size denotes the amount of memory we want to assign to Metaspace.

As per the Oracle guidelines, after total available memory, the second most influential factor is the proportion of the heap reserved for the Young Generation. By default, the minimum size of the YG is 1310 MB, and maximum size is unlimited.

We can assign them explicitly:

-XX:NewSize=<young size>[unit] 
-XX:MaxNewSize=<young size>[unit]

3. Garbage Collection

For better stability of the application, choosing the right Garbage Collection algorithm is critical.

JVM has four types of GC implementations:

• Serial Garbage Collector
• Parallel Garbage Collector
• CMS Garbage Collector
• G1 Garbage Collector

We can declare these implementations with the below parameters:

-XX:+UseSerialGC
-XX:+UseParallelGC
-XX:+USeParNewGC
-XX:+UseG1GC

And we can find more details on Garbage Collection implementations here.

4. GC Logging

To strictly monitor the application health, we should always check the JVM’s Garbage Collection performance. The easiest way to do this is to log the GC activity in human readable format.

Using the following parameters, we can log the GC activity:

-XX:+UseGCLogFileRotation 
-XX:NumberOfGCLogFiles=< number of log files > 
-XX:GCLogFileSize=< file size >[ unit ]
-Xloggc:/path/to/gc.log

UseGCLogFileRotation specifies the log file rolling policy, much like log4j, s4lj, etc. NumberOfGCLogFiles denotes the max number of log files we can write for a single application life cycle. GCLogFileSize specifies the max size of the file. Finally, loggc denotes its location.

One point to note here is that there are two more JVM parameters available (-XX:+PrintGCTimeStamps and -XX:+PrintGCDateStamps) that we can use to print date-wise timestamps in the GC log.

For example, if we want to assign a maximum of 100 GC log files, each having a maximum size of 50 MB, and we want to store them in the ‘/home/user/log/’ location, we can use the below syntax:

-XX:+UseGCLogFileRotation  
-XX:NumberOfGCLogFiles=10
-XX:GCLogFileSize=50M 
-Xloggc:/home/user/log/gc.log

However, the problem is that one additional daemon thread is always used for monitoring system time in the background. This behavior may create some performance bottleneck, which is why it’s better to not play with this parameter in production.

5. Handling out of Memory

It’s very common for a large application to face an out of memory error, which in turn results in an application crash. It’s a very critical scenario, and very hard to replicate to troubleshoot the issue.

That’s why JVM comes with some parameters to dump heap memory into a physical file that we can use later to find leaks:

-XX:+HeapDumpOnOutOfMemoryError 
-XX:HeapDumpPath=./java_pid<pid>.hprof
-XX:OnOutOfMemoryError="< cmd args >;< cmd args >" 
-XX:+UseGCOverheadLimit

A couple of points to note here:

• HeapDumpOnOutOfMemoryError instructs the JVM to dump heap into a physical file in case of OutOfMemoryError.
• HeapDumpPath denotes the path where the file will be written. Any filename can be given; however, if JVM finds a <pid> tag in the name, the process id of the current process causing the out of memory error will be appended to the file name with .hprof format.
• OnOutOfMemoryError is used to issue emergency commands that will be executed in case of an out of memory error. We should use proper commands in the space of cmd args. For example, if we want to restart the server as soon as an out of memory occurs, we can set the parameter:

-XX:OnOutOfMemoryError="shutdown -r"

• UseGCOverheadLimit is a policy that limits the proportion of the VM’s time that’s spent in GC before an OutOfMemory error is thrown.

6. 32/64 Bit

In an OS environment where we’ve installed both 32 and 64-bit packages, the JVM automatically chooses the 32-bit environmental packages.

If we want to set the environment to 64 bit manually, we can do so using the below parameter:

-d<OS bit>

OS bit can be either 32 or 64. We can find more information about this here.

7. Misc

• -server: enables “Server Hotspot VM.” We use this parameter by default in 64 bit JVM.
• -XX:+UseStringDeduplication: Java 8u20 has introduced this JVM parameter for reducing the unnecessary use of memory by creating too many instances of the same String. This optimizes the heap memory by reducing duplicate String values to a single global char[] array.
• -XX:+UseLWPSynchronization: sets a LWP (Light Weight Process) based synchronization policy instead of thread-based synchronization.
• -XX:LargePageSizeInBytes: sets the large page size used for the Java heap. It takes the argument in GB/MB/KB. With larger page sizes, we can make better use of virtual memory hardware resources; however, this may cause larger space sizes for the PermGen, which in turn can force us to reduce the size of the Java heap space.
• -XX:MaxHeapFreeRatio: sets the maximum percentage of heap free after GC to avoid shrinking
• -XX:MinHeapFreeRatio: sets the minimum percentage of heap free after GC to avoid expansion. To monitor the heap usage, we can use VisualVM shipped with JDK.
• -XX:SurvivorRatio: Ratio of eden/survivor space size. For example, -XX:SurvivorRatio=6 sets the ratio between each survivor space and eden space to be 1:6.
• -XX:+UseLargePages: use large page memory if the system supports it. Please note that OpenJDK 7 tends to crash if using this JVM parameter.
  
• -XX:+UseStringCache: enables caching of commonly allocated strings available in the String pool
  
• -XX:+UseCompressedStrings: use a byte[] type for String objects which can be represented in pure ASCII format
• -XX:+OptimizeStringConcat: it optimizes String concatenation operations where possible
  

8. Conclusion

In this brief article, we learned about some important JVM parameters, which we can use to tune and improve general application performance. We can also use some of these for debugging purposes.

To explore the reference parameters in more detail, we can take a look here.