views:

15870

answers:

5

Given these two commands

A:

$ java -Xms10G -Xmx10G myjavacode input.txt

B:

$ java -Xms5G -Xmx5G myjavacode input.txt

I have two questions:

  1. Since command A reserves more memory with its parameters, will A run faster than B?
  2. How do -Xmx and -Xms affect the running process and the output of my program?
+3  A: 

It depends on the GC your java is using. Parallel GCs might work better on larger memory settings - I'm no expert on that though.

In general, if you have larger memory the less frequent it needs to be GC-ed - there is lots of room for garbage. However, when it comes to a GC, the GC has to work on more memory - which in turn might be slower.

kd304
@kd304: So if my CPU has large RAM (say 10GB), and let say that is enough for my app to run. Do you mean the less memory as in Xmx/Xms param we use the faster my code will run?
neversaint
@kd304: btw, how can I check the GC of my java I am using?
neversaint
CPUs don't have ram.
jjnguy
@jinguy: I stand corrected, I mean my PC.
neversaint
Hard to say as performance depends on many things. I would say you could find a balance between the memory size and the GC runtime cost. Unfortunately, I don't know where you could check what kind of GC is default for your java version. If you want you can even change the GC's type via command line parameters.
kd304
Overall time spent on GC does NOT increase with the amount of RAM, unless you have a pathological case with lots of full GCs. The usual concern with lots of RAM is that it can lead to no full GC being performed for a long time, followed by the app locking up while it finally performs the GC it has deferred for so long.
Michael Borgwardt
@Michael Borgwardt: I thought I described the same thing as your 2nd sentence.
kd304
May I ask the reason for the downvote so I can learn from it?
kd304
+1  A: 

Using those command line options do not affect speed in any way.

They can be useful for expanding the amount of memory the JVM is allowed to use. You may need to do this if your Java app needs a lot of memory to run.

The GC speed/frequency may be affected, but I wouldn't try to optimize your program for GC speed.

jjnguy
Actually, optimized GC can be essential for performance in applications with huge in-memory working sets.
Michael Borgwardt
*can* I would make sure everything else is optimized before fooling with GC.
jjnguy
That is not correct. Memory settings can have a *huge* impact on speed. In particular, if the JVM has almost no free RAM left, it will spend most of its runtime desperatly GCing :-(.
sleske
It is true that the options will make no difference *as long as the JVM has enough RAM to do its job*. I guess that's what you meant by "do no affect speed" ...
sleske
+1  A: 

It is difficult to say how the memory allocation will affect your speed. It depends on the garbage collection algorithm the JVM is using. For example if your garbage collector needs to pause to do a full collection, then if you have 10 more memory than you really need then the collector will have 10 more garbage to clean up.

If you are using java 6 you can use the jconsole (in the bin directory of the jdk) to attach to your process and watch how the collector is behaving. In general the collectors are very smart and you won't need to do any tuning, but if you have a need there are numerous options you have use to further tune the collection process.

pfranza
+11  A: 

The -Xmx argument defines the max memory size that the heap can reach for the JVM. You must know your program well and see how it performs under load and set this parameter accordingly. A low value can cause OutOfMemoryExceptions or a very poor performance if your program's heap memory is reaching the maximum heap size. If your program is running in dedicated server you can set this parameter higher because it wont affect other programs.

The -Xms argument sets the initial heap memory size for the JVM. This means that when you start your program the JVM will allocate this amount of memory instantly. This is useful if your program will consume a large amount of heap memory right from the start. This avoids the JVM to be constantly increasing the heap and can gain some performance there. If you don't know if this parameter is going to help you, don't use it.

In summary, this is a compromise that you have to decide based only in the memory behavior of your program.

bruno conde
+1  A: 
  1. Allocation always depends on your OS. If you allocate too much memory, you could end up having loaded portions into swap, which indeed is slow.
  2. Whether your program runs slower or faster depends on the references the VM has to handle and to clean. The GC doesn't have to sweep through the allocated memory to find abandoned objects. It knows it's objects and the amount of memory they allocate by reference mapping. So sweeping just depends on the size of your objects. If your program behaves the same in both cases, the only performance impact should be on VM startup, when the VM tries to allocate memory provided by your OS and if you use the swap (which again leads to 1.)
oeogijjowefi