What are -Xms and -Xms parameters in Java/JVM (Updated up to Java 13)02 Sep 2019
Xmxspecifies the maximum heap size available to an application
Xmsspecifies the minimum heap size available to an application
These are Java Virtual Machine (JVM) parameters that are used to specify memory boundaries for Java applications. They are often used when troubleshooting performance issues or OutOfMemoryErrors. They control the amount of memory that is available to a Java application. The
Xmx parameter specifies the maximum memory an app can use, where as
Xms specifies the minimum or the initial memory pool. If your application exceeds the maximum memory (allocated using the
Xmx) and the garbage collector cannot free up memory, the JVM will crash with a OutOfMemoryError. If you’re interested, I wrote an article explaining with examples how garbage collection works and its generations.
$ java -Xmx256m Xmx1024m -jar yourapp.jar
In the example above, the application
yourapp.jar will get an initial memory pool of 256 megabytes and a maximum up to 1024 megabytes. In
m stands for megabytes. You can use
G to indicate gigabytes.
Xmx1G: Set the maximum memory size to 1 gigabytes.
Xmx1024M: Set the maximum memory size to 1024 megabytes.
Xmx1024000K: Sets the maximum memory size to 1024000 kilobytes.
It’s important to note that both
Xms are optional. If these are not provided, the Java Virtual Machine (JVM) will use default values for them. The default values depend on your machine and the JVM configuration. For server class machines, these are defined as:
- Initial heap size of 1/64 of physical memory (for
- Maximum heap size of 1/4 of physical memory (for
In the example below, the maximum memory will be limited to 1024 megabytes. The initial memory (what
Xms parameter represents will use the default value.)
java -Xmx1024m -jar yourapp.jar
Here’s a good YouTube video that walks through the process of troubleshooting memory related errors and shows to fix them using examples.
Java 13 and the Z Garbage Collector
Java 13 introduced a new garbage collector called ZGC. One of its features includes an optimization to return un-used memory to the operating system. This feature is enabled by default and it will not return memory such that heap size shrinks below
Xms. So if you’re setting
Xms to equal
Xmx (as many developers do,) it will essentially disable the feature.
If you want to see all available JVM parameters, you can use the
java -X switch e.g.
$ java -X -Xmixed mixed mode execution (default) -Xint interpreted mode execution only -Xbootclasspath:<directories and zip/jar files separated by :> set search path for bootstrap classes and resources -Xbootclasspath/a:<directories and zip/jar files separated by :> append to end of bootstrap class path -Xbootclasspath/p:<directories and zip/jar files separated by :> prepend in front of bootstrap class path -Xdiag show additional diagnostic messages -Xnoclassgc disable class garbage collection -Xincgc enable incremental garbage collection -Xloggc:
log GC status to a file with time stamps -Xbatch disable background compilation -Xms set initial Java heap size -Xmx set maximum Java heap size -Xss set java thread stack size -Xprof output cpu profiling data -Xfuture enable strictest checks, anticipating future default -Xrs reduce use of OS signals by Java/VM (see documentation) -Xcheck:jni perform additional checks for JNI functions -Xshare:off do not attempt to use shared class data -Xshare:auto use shared class data if possible (default) -Xshare:on require using shared class data, otherwise fail. -XshowSettings show all settings and continue -XshowSettings:all show all settings and continue -XshowSettings:vm show all vm related settings and continue -XshowSettings:properties show all property settings and continue -XshowSettings:locale show all locale related settings and continue The -X options are non-standard and subject to change without notice. </pre>