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.
Table of Contents
However, you don’t need to remember all the parameters; you just need to know about Java VM parameters and how to use them.
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:
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,
-Xmx<Heap Size>[Unit]
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
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,
-Xms<Heap Size>[Unit]
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,
-Xms1G –Xmx3G
In this example, 1GB is the minimum Heap memory to be assigned and 3GB is the maximum.
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
-XX:NewSize=<young size>[k|m|G]
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:NewSize=1024m -XX:NewSize=1G
It is used to set the maximum possible size of the heap memory for the young generation. Like this,
-XX:MaxNewSize=1024m
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
-XX:MaxPermSize=size -XX:PermSize=size
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 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,
It is disabled by default; you can enable it for printing messages at every GC event.
-XX:+PrintGCDetails
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.
-XX:+PrintGCDateStamps
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,
-Xloggc:/home/FILES/gc.log
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:+UseGCLogFileRotation
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:NumberOfGCLogFiles=4
This parameter defines the size of the log file when it will be rotated; its default size is always set to 512KB.
-XX:GCLogFileSize=20M
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:HeapDumpPath=./java_pid<pid>.hprof
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,
-XX:OnOutOfMemoryError="shutdown -r"
It is used to limit the amount of time that JVM spends in the GC process before an OutOfMemoryError is thrown.
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,
-Duser.timezone=US/Eastern
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:
-d<OS bit>
It will be -d32 for a 32-bit environment or -d64 for a 64-bit environment.
See Also: Here’s How to Fix the “Could Not Find or Load Main Class” Error in Java
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.
Shaharyar Lalani is a developer with a strong interest in business analysis, project management, and UX design. He writes and teaches extensively on themes current in the world of web and app development, especially in Java technology.
Create a free profile and find your next great opportunity.
Sign up and find a perfect match for your team.
Xperti vets skilled professionals with its unique talent-matching process.
Connect and engage with technology enthusiasts.
© Xperti.io All Rights Reserved
Privacy
Terms of use