Duplicate Java execution options: what is the order of preference?

Question

Given the following command line

java -Xms128m -Xms256m myapp.jar 

What settings will be applied for the JVM? Minimum memory ( Xms option): 128 m or 256 m?

Answer 1

Depends on the JVM, maybe on the version ... maybe even on the amount of paperclip on your desk at that time. It may not even work. Do not do this.

If for some reason it doesn’t work, compile and run it the same way you run your jar. But be careful when relying on the order of options - this 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()); } } 

Answer 2

As always, check the local specific implementation of the JVM, but here is a quick way to check from the command line without the need for 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, in this case, you will see that the second instance of the argument (2G) takes precedence (at least in version 1.8), and that was my experience with most other modern versions.

Answer 3

The IBM JVM considers the rightmost instance of the argument as the winner. I can not talk with HotSpot, etc.

We do this because often nested command lines are from batch files, where people can only add to the end and want to make it a winner.

Answer 4

FTR, OpenJDK 1.7 also seems to have the rightmost meaning, at least for -Xms.

Answer 5

I put him second. Arguments are usually processed in the following order:

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

But if I were writing a java argument parser, I would complain about conflicting arguments.