Should -Xmx be a multiple of -Xms?

[Tom Anderson]

Hello,

A colleague mentioned that he'd heard (from this guy's cousin's mechanic's
guy who he met in a bar's grandfather's dealer's sysop) that the JVM
requests memory from the OS in chunks of the size of -Xms, and that you
should therefore always set -Xmx to be a whole multiple of -Xms, otherwise
it would never actually request its way up to it (because you can't make a
litre from any whole number of fluid ounces).

I think i'd heard something similar at some point, although from a less
reliable source.

Is there any truth to this? Was there ever?

tom

 

[Daniel Pitts]

Hello,

A colleague mentioned that he'd heard (from this guy's cousin's
mechanic's guy who he met in a bar's grandfather's dealer's sysop) that
the JVM requests memory from the OS in chunks of the size of -Xms, and
that you should therefore always set -Xmx to be a whole multiple of
-Xms, otherwise it would never actually request its way up to it
(because you can't make a litre from any whole number of fluid ounces).

I think i'd heard something similar at some point, although from a less
reliable source.

Is there any truth to this? Was there ever?

This doesn't sound true to me. I would even venture that the JVM is
likely to use an exponential algorithm instead of a multipling one, eg.
when the heap needs to grow, it doubles in size. I would also guess
that it would "cap" the value to -Xmx *after* it tries to double, so
that you still use the full -Xmx value.

This, of course, is just speculation on my part. I'm under the
impression that nothing in the JVM is still a "naive" implementation,
and one would have to be pretty naive to implement the growth function
that way.

 

[Lew]

This doesn't sound true to me. I would even venture that the JVM is
likely to use an exponential algorithm instead of a multipling one, eg.
when the heap needs to grow, it doubles in size. I would also guess that
it would "cap" the value to -Xmx *after* it tries to double, so that you
still use the full -Xmx value.

This, of course, is just speculation on my part. I'm under the
impression that nothing in the JVM is still a "naive" implementation,
and one would have to be pretty naive to implement the growth function
that way.

Given how many pieces constitute the "heap" - you have your eden, your
young-generation space, your survivor space, your tenured generation and your
"virtual" young and tenured spaces, and the fact that the JVM dynamically
alters the sizes of these components to meet its ergonomic goals according to
the selected GC strategy, it seems extremely unlikely that what tom heard is
anything more than urban legend.

The ergonomics white papers on java.sun.com tell us that the JVM reserves the
-Xmx value from the OS at the get go, but doesn't physically acquire the heap
between that value and -Xms until needed.

I spent a little time reading around to try to find any evidence for or
against. There is no comment anywhere about such a strategy, leading me to
conclude that there is no such strategy, and even if there were it would be an
artifact of a particular version of a particular brand of JVM with no promise
that that behavior will hold in other versions or brands.

I consider this myth BUSTED.

 

[Arne Vajhøj]

A colleague mentioned that he'd heard (from this guy's cousin's
mechanic's guy who he met in a bar's grandfather's dealer's sysop) that
the JVM requests memory from the OS in chunks of the size of -Xms, and
that you should therefore always set -Xmx to be a whole multiple of
-Xms, otherwise it would never actually request its way up to it
(because you can't make a litre from any whole number of fluid ounces).

I think i'd heard something similar at some point, although from a less
reliable source.

Is there any truth to this? Was there ever?

No truth with SUN Java 1.6.

I very much doubt there was any truth with other implementations. But
one never knows.

To very try run this with various Xms and Xmx:

import java.util.ArrayList;
import java.util.List;

public class MemIncr {
public static void main(String[] args) {
Runtime rt = Runtime.getRuntime();
List<byte[]> lst = new ArrayList<byte[]>();
while(true) {
System.out.println((rt.totalMemory() - rt.freeMemory()) + "
out of " + rt.totalMemory() + " used (max is " + rt.maxMemory() + ")");
lst.add(new byte[1000000]);
}
}
}

Arne

 

[Mike Schilling]

Hello,

A colleague mentioned that he'd heard (from this guy's cousin's mechanic's
guy who he met in a bar's grandfather's dealer's sysop)

More reliable than seeing it on Usenet, anyway.

 

[Kevin McMurtrie]

Hello,

A colleague mentioned that he'd heard (from this guy's cousin's mechanic's
guy who he met in a bar's grandfather's dealer's sysop) that the JVM
requests memory from the OS in chunks of the size of -Xms, and that you
should therefore always set -Xmx to be a whole multiple of -Xms, otherwise
it would never actually request its way up to it (because you can't make a
litre from any whole number of fluid ounces).

I think i'd heard something similar at some point, although from a less
reliable source.

Is there any truth to this? Was there ever?

tom

Nope.

I don't know if it holds true for 1.6, but heap growth had performance
problems in 1.4 and 1.5 so setting ms and mx to the same value helped
some applications. Searching bug reports are a great way to gather
information about edge cases like this.

 

[Mike Schilling]

I don't know if it holds true for 1.6, but heap growth had performance
problems in 1.4 and 1.5 so setting ms and mx to the same value helped
some applications. Searching bug reports are a great way to gather
information about edge cases like this.

It's still true that if you know the app will grown to at least N during its
life, you might as well set ms to N. Otherwise you're just causing
unnecessarily expensive GCs while it grows.

 

[Daniel Pitts]

It's still true that if you know the app will grown to at least N during
its life, you might as well set ms to N. Otherwise you're just causing
unnecessarily expensive GCs while it grows.

Set which? MX or MS?

 

[Lew]

Set which? MX or MS?

 

[Daniel Pitts]

Ah, my mind must have filtered "ms" into "it" for some reason.

Anyway, I disagree about that. I would think that ms should be set to
the "average case", and mx to the "worst case that we want to succeed"

 

[Arne Vajhøj]

Ah, my mind must have filtered "ms" into "it" for some reason.

Anyway, I disagree about that. I would think that ms should be set to
the "average case", and mx to the "worst case that we want to succeed"

Mike was not even that aggressive - he just wanted to set to the
minimum.

#if you know the app will grown to at least N during its life, you
#might as well set ms to N

Arne

 

[Mike Schilling]

Set which? MX or MS?

ms, as I said.