Re: Should -Xmx be a multiple of -Xms?
Tom Anderson wrote:
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?
Daniel Pitts wrote:
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.
--
Lew