Sun's 1.5 JVM: the -XX:DefaultMaxRAM option and its cousins


Sun's 1.5 JVM has some heap size configuration parameters that are not
available in their 1.4 and earlier JVMs.

For Sun's 1.5 JVM (not 1.4), there is the following documentation on
sun's website:

If not otherwise set on the command line, the sizes of the initial
heap and maximum heap are calculated based on the size of the physical
memory. If phys_mem is the size of the physical memory on the
platform, the initial heap size will be set to phys_mem /
DefaultInitialRAMFraction. DefaultInitialRAMFraction is a command line
option with a default value of 64.
Similarly the maximum heap size will be set to phys_mem /
DefaultMaxRAMFraction has a default value of 4.
<end of fragment>

Does the second to the last line, in the above fragment, have a typo?
Shouldn't it read:
"Similarly the maximum heap size will be set to phys_mem /


I am thinking it's a typo because I just looked at:

You can further control the heap size through the following new


DefaultInitialRAMFraction has a default value of 64.
DefaultMaxRAMFraction has a default value of 4. The default initial
size of the heap is the size of physical RAM divided by
DefaultInitialRAMFraction. You can either set the maximum size
explicitly with DefaultMaxRAM
or use DefaultMaxRAMFraction to set the value proportionally.


Also, why did they create the "-XX:DefaultMaxRAM" option, when there is
already the
"-Xmx" option that is available in 1.5 (and was also available in
earlier JVMs) ? I can see the reason for the
"-XX:DefaultInitialRAMFraction" and the "-XX:DefaultMaxRAMFraction"
options, but the "XX:DefaultMaxRAM" option seems redundant with the
"-Xmx" option.

You would think Sun would do a better job of documenting these options.


Relevant Pages

  • Re: Help me!! Why java is so popular
    ... For Sun's JVM the option -Xms is used to specify the minimum heap size. ... Within the min/max limits the heap will grow and shrink as required, although it doesn't always shrink as quickly as might be desirable. ... It may be that your web server system configured the JVM with a high minimum value for the heap. ...
  • Re: one thread is created for each object construction?
    ... The object "e" is represented by a data structure on the heap. ... There is bytecode at a location in the JVM that represents the data and methods of the object. ... Construction of an object does not spawn a new thread, not in the JVM, not anywhere, not nohow. ... (Of course, it is possible that someone somewhere might write a JVM that violates this, but it doesn't change the conceptual model. ...
  • Re: Need help
    ... > records" on the heap, and let the garbage collector clean up the mess ... facility in Java or the JVM for returning references to locals... ... can't see any reason why a JVM would need to heap allocate activation ... > at least one C compiler that uses heap allocated stacks. ...
  • Re: Problem running my java app on Netbeans
    ... It also has nothing whatsoever to do with the JVM's ability to allocate memory from the OS. ... Mike is correct that a 32-bit JVM is limited to somewhat less than 2 GB heap, the exact limit depending on the OS. ... The amount of RAM that the OS shows the JVM to use is only tangentially related to the amount of free heap controlled by the JVM within itself. ...
  • Re: bind CPUs to the process?
    ... > would be more suitable for constraining CPU use, ... > get stuck into segment 2 at exec, the heap for dynamic loads. ... I don't think the JVM supports DSA (dynamic segment ... sacrificing segments available for shared memory segments). ...