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

-- 
unstable orbits in the space of lies

On 6/1/2010 11:06 AM, Tom Anderson wrote:
> 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.

-- 
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>

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

On 01-06-2010 14:06, 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?

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

"Tom Anderson" <twic@urchin.earth.li> wrote in message 
news:alpine.DEB.1.10.1006011632420.16785@urchin.earth.li...
> 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.
 

In article <alpine.DEB.1.10.1006011632420.16785@urchin.earth.li>,
 Tom Anderson <twic@urchin.earth.li> wrote:

> 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.
-- 
I won't see Google Groups replies because I must filter them as spam

"Kevin McMurtrie" <mcmurtrie@pixelmemory.us> wrote in message 
news:4c05e127$0$22132$742ec2ed@news.sonic.net...

>
> 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. 

On 6/1/2010 9:59 PM, Mike Schilling wrote:
>
>
> "Kevin McMurtrie" <mcmurtrie@pixelmemory.us> wrote in message
> news:4c05e127$0$22132$742ec2ed@news.sonic.net...
>
>>
>> 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.
Set which? MX or MS?

-- 
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>

Mike Schilling wrote:
>> ... you might as well set ms to N.

Daniel Pitts wrote:
> Set which? MX or MS?

-- 
Lew

On 6/2/2010 3:44 PM, Lew wrote:
> Mike Schilling wrote:
>>> ... you might as well set ms to N.
>
> Daniel Pitts wrote:
>> Set which? MX or MS?
>
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"


-- 
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>

On 02-06-2010 19:09, Daniel Pitts wrote:
> On 6/2/2010 3:44 PM, Lew wrote:
>> Mike Schilling wrote:
>>>> ... you might as well set ms to N.
>>
>> Daniel Pitts wrote:
>>> Set which? MX or MS?
>>
> 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

"Daniel Pitts" <newsgroup.spamfilter@virtualinfinity.net> wrote in message 
news:WmxNn.88775$_84.2526@newsfe18.iad...
> On 6/1/2010 9:59 PM, Mike Schilling wrote:
>>
>>
>> "Kevin McMurtrie" <mcmurtrie@pixelmemory.us> wrote in message
>> news:4c05e127$0$22132$742ec2ed@news.sonic.net...
>>
>>>
>>> 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.
> Set which? MX or MS?

 ms, as I said.