Duplicated Java runtime options : what is the order of preference?

JavaJvmJvm ArgumentsJava Opts

Java Problem Overview


Considering the following command line

java -Xms128m -Xms256m myapp.jar

Which settings will apply for JVM Minimum memory (Xms option) : 128m or 256m ?

Java Solutions


Solution 1 - Java

As always, check your local JVM's specific implementation but here is a quick way to check from the command line without having to code.

> java -version; java -Xmx1G -XX:+PrintFlagsFinal -Xmx2G 2>/dev/null | grep MaxHeapSize

java version "1.8.0_25"
Java(TM) SE Runtime Environment (build 1.8.0_25-b17)
Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode)
uintx MaxHeapSize         := 2147483648        {product}

So you'll see in this case, the second instance of the argument (2G) is what takes precedence (at least in 1.8) and that has been my experience with most other modern versions as well.

Solution 2 - Java

The IBM JVM treats the rightmost instance of an argument as the winner. I can't speak to HotSpot, etc..

We do this as there are often deeply nested command lines from batch files where people can only add to the end, and want to make that the winner.

Solution 3 - Java

FTR, OpenJDK 1.7 also seems to take the rightmost value, at least for -Xms.

Solution 4 - Java

Depends on the JVM, perhaps the version...perhaps even how many paper clips you have on your desk at the time. It might not even work. Don't do that.

If it's out of your control for some reason, compile and run this the same way you'd run your jar. But be warned, relying on the order of the options is a really bad idea.

public class TotalMemory
{
    public static void main(String[] args)
    {
         System.out.println("Total Memory: "+Runtime.getRuntime().totalMemory());
         System.out.println("Free Memory: "+Runtime.getRuntime().freeMemory());
    }
}

Solution 5 - Java

> Which settings will apply for JVM Minimum memory?

In the various versions of Java listed below, the "winner" is the right-most value in the argument list. As others have pointed out, it is not a good idea to rely on this, but perhaps this is useful information to share nonetheless.

Java 1.8.0_172

~ $ java8
java version "1.8.0_172"
Java(TM) SE Runtime Environment (build 1.8.0_172-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.172-b11, mixed mode)
~ $ java -Xmx1024m -Xmx4024m -XX:+PrintFlagsFinal Test 2>/dev/null | grep MaxHeapSize
    uintx MaxHeapSize                              := 4219469824                          {product}

Java 11.0.3

~ $ java11
java version "11.0.3" 2019-04-16 LTS
Java(TM) SE Runtime Environment 18.9 (build 11.0.3+12-LTS)
Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.3+12-LTS, mixed mode)
~ $ java -Xmx1024m -Xmx4024m -XX:+PrintFlagsFinal Test 2>/dev/null | grep MaxHeapSize
   size_t MaxHeapSize                              = 4219469824                                {product} {command line}

OpenJDK 12.0.1

~ $ java12
openjdk version "12.0.1" 2019-04-16
OpenJDK Runtime Environment (build 12.0.1+12)
OpenJDK 64-Bit Server VM (build 12.0.1+12, mixed mode, sharing)
~ $ java -Xmx1024m -Xmx4024m -XX:+PrintFlagsFinal Test 2>/dev/null | grep MaxHeapSize
   size_t MaxHeapSize                              = 4219469824                                {product} {command line}

AdoptOpenJDK 12.0.1

~ $ java12a
openjdk version "12.0.1" 2019-04-16
OpenJDK Runtime Environment AdoptOpenJDK (build 12.0.1+12)
OpenJDK 64-Bit Server VM AdoptOpenJDK (build 12.0.1+12, mixed mode, sharing)
~ $ java -Xmx1024m -Xmx4024m -XX:+PrintFlagsFinal Test 2>/dev/null | grep MaxHeapSize
   size_t MaxHeapSize                              = 4219469824                                {product} {command line}

OpenJDK 13-ea

~ $ java13
openjdk version "13-ea" 2019-09-17
OpenJDK Runtime Environment (build 13-ea+22)
OpenJDK 64-Bit Server VM (build 13-ea+22, mixed mode, sharing)
~ $ java -Xmx1024m -Xmx4024m -XX:+PrintFlagsFinal Test 2>/dev/null | grep MaxHeapSize
   size_t MaxHeapSize                              = 4219469824                                {product} {command line}

Solution 6 - Java

I bet it's the second one. Arguments are usually processed in the order:

for( int i=0; i<argc; i++ ) {
  process_argument(argv[i]);
}

But if I were writing java argument parser, I'd complain on conflicting arguments.

Solution 7 - Java

My experiments show that it takes the maximum value of xmx.

So if you pass in -xmx4g -xmx1g it will take 4t, and if you pass in -xmx1g -xmx4g it will still take 4g.

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
Questionfabien7474View Question on Stackoverflow
Solution 1 - JavaDavid HergertView Answer on Stackoverflow
Solution 2 - JavaTrent Gray-DonaldView Answer on Stackoverflow
Solution 3 - JavaMarcin OwsianyView Answer on Stackoverflow
Solution 4 - JavacHaoView Answer on Stackoverflow
Solution 5 - JavakaanView Answer on Stackoverflow
Solution 6 - JavaVladimir DyuzhevView Answer on Stackoverflow
Solution 7 - JavaDataDudeView Answer on Stackoverflow