Currently, there are more than 600 Java VM parameters just for garbage collection and memory. If we include the parameters for other aspects as well, the number will go up significantly. These are way too many parameters to remember even for an experienced Java developer.
However, you don’t need to remember all the parameters; you just need to know about Java VM parameters and how to use them.
JVM parameters for heap memory management
One of the main optimization features of JVM involves assigning the right amount of minimum and maximum heap memory to the JVM as per the requirement of the application. Following are the prominent Java VM parameters use to manage heap memory:
-Xmxsize (Maximum heap size)
It is used to specify the maximum size of the heap memory to be assigned to the JVM. Following convention can be used for assignment,
Here, Heap size denotes the heap size to be assigned and it should be a multiple of 1024. The unit tells the unit of the memory that we want to specify to the JVM. You can add the letter ‘k/K’ to indicate kilobytes, ‘m/M’ for megabytes, and ‘g/G’ for gigabytes.
See this example where a maximum of 6GB of memory is assigned to JVM, all 3 of the following parameters are correct,
-Xmx6G -Xmx6000m -Xmx6442450944
-Xmssize (Minimum heap size)
Xms is used to specify the minimum size of the heap memory to be assigned. Its convention is very similar to the maximum heap size parameter,
Following examples are for assigning the minimum of 2GB of heap memory to the JVM,
-Xms2147482548 -Xms2000m -Xms2G
Both of the above parameters can be used together for assigning a range of heap memory to JVM like this,
In this example, 1GB is the minimum Heap memory to be assigned and 3GB is the maximum.
-XX:NewSize=size (Young generation heap size)
The young generation part of the heap is used to assign the memory to newly created objects; it is considered one of the most important Java VM parameters besides -Xmx and –Xms.
Following convention is used to set size for the young generation
The initial size of the young generation can be set to 1GB, using the following line of code any of the following lines of code
-XX:MaxNewSize=size (Young generation max heap size)
It is used to set the maximum possible size of the heap memory for the young generation. Like this,
Following two Java VM parameters were also once used to manage heap memory but they have been removed from Java 8. It is recommended not to use these parameters in your application
JVM parameters for garbage collection algorithms
To keep your application stable while running, it is very crucial to choose the correct garbage collection (GC) algorithm for it.
There are seven different algorithms available for GC implementation in JVM. You need to explicitly specify the GC algorithm you want to use or else JVM will go with the default algorithm. Until Java version 8, Parallel GC is the default algorithm but if you are using Java 9, G1 will be the default algorithm.
Following are the seven algorithms along with the Java VM parameters to activate each one of them
|Garbage Collection Algorithm||JVM Parameters|
|Concurrent Market & Sweep (CMS) GC||-XX:+UseConcMarkSweepGC|
Garbage collection logging
Garbage Collection logs contain all the information about GC events. It includes the amount of memory claimed and reclaimed, pause time duration, etc. This information proves to be very helpful when it comes to debugging memory leaks or application performance, but you need to first enable the GC logging by using specific Java VM parameters.
Following are some of the JVM parameters you need to know to manage GC logs,
-XX:+PrintGCDetails (Print GC details messages)
It is disabled by default; you can enable it for printing messages at every GC event.
-XX:+PrintGCDateStamps (Print GC details messages)
This parameter can be used for printing the date stamp at every GC event; it is also disabled by default and needs to be enabled to be used.
-Xloggc:<filename> (Set file for GC output)
You can set the file name and the location to which the GC output will be then redirected. The <filename> will be replaced with the file location like this,
-XX:+UseGCLogFileRotation (Log rotations)
This parameter enables the log rotations. It is more useful when you are dealing with large log files produced by long-running Java Applications. This parameter must be used with -Xloggc:<filename> to redirect the log output with every rotation.
-XX:NumberOfGClogFiles=<number of files> (Set number of files)
It is used to set the number of files to be used when rotating the logs, the default value is always set to 1 but you can increase it depending on the requirement of the application. The number of files must be at least 1.
-XX:GCLogFileSize=<fileSize> (Set log File Size)
This parameter defines the size of the log file when it will be rotated; its default size is always set to 512KB.
JVM parameters for handling out of memory
A large Java application could likely face the OutOfMemoryError which results in the crashing of the application. It is a very critical scenario and it gets very difficult to find the root cause to troubleshoot the issue. To resolve this, JVM has some parameters that dump the heap memory into a physical file which can be later used to find the memory leaks,
It is used to instruct the JVM to dump the heap into a physical file in the case of OutOfMemoryError.
This parameter tells the path where the file is to be saved; although any filename can be entered here, if you add a <pid> tag in the file name, the process id of the current process that is causing the OutOfMemoryError will be used to name the file with .hprof format.
-XX:OnOutOfMemoryError=”< cmd args >”
It is used to issue the emergency command(s) to be executed if OutOfMemoryError is encountered; proper command must be used in the space of cmd args. For example, the following parameter will be set to restart the server in case of OutOfMemoryError,
It is used to limit the amount of time that JVM spends in the GC process before an OutOfMemoryError is thrown.
JVM parameter to set time Zone
Some applications have very sensitive business requirements based on time/date. For example, if you are building a movie streaming application, you might have to make a movie available at a certain time. To implement these date/time requirements, you would be probably using the java. util.Date or java. util.Calendar objects.
These objects pick the time zone information by default from the operating system. Now, this can become a problem in certain scenarios.
Let’s say if your application is running across multiple data centers around the globe then JVMs in each data center will end up having different time zones which can likely result in inconsistent results.
In another case, if you are deploying your application in a cloud environment, your application could be moved to different data centers without your knowledge.
To avoid these inconsistencies, it is recommended to set your JVM time zone using the Duser. timezone system property. The parameters for this are the time zone you want to work with like if you want to set EDT time zone for your application, It can be done like this,
JVM parameter to select 32/64 bit packages
In certain operating system environments where both 32 and 64-bit packages are installed, the JVM will automatically choose the 32-bit environmental packages by default. If you want to set the environment to 64 bit, you need to do it manually. It can be done using the following JVM parameter:
It will be -d32 for a 32-bit environment or -d64 for a 64-bit environment.
In this article, we have discussed some of the most important Java VM parameters and their proper usage. These parameters come in handy while debugging and error detection and they manage very important aspects of your application by optimizing and configuring JVM based on the application’s requirements.