Sun's JVM heap size limit on Ubuntu 64-bit

Question

I see some strange behavior on the maximum heap size I get on Sun's JVM, compared to JRockit.

I'm running IDEA on 64-bit VMs on a 64-bit system (Ubuntu 11.04). The JVM versions I'm testing are: Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode) (which I got with apt-get install sun-java6-jdk, and Oracle JRockit(R) (build R28.1.3-11-141760-1.6.0_24-20110301-1432-linux-x86_64, compiled mode) (which I downloaded from Oracle's site a couple of months ago).

If I pass the parameters -Xms1g -Xmx3g, IDEA will report a maximum heap size of 1820M on Sun's JVM, and 3072M (as expected) on JRockit.

If I pass -Xms2g -Xmx4g, IDEA will report 3640M on Sun's and 4096M on JRockit.

What is happening? What are those mystic numbers 1820M and 3640M = 2*1820M? Isn't it possible to run Sun's JVM with the exact heap size I want?

EDIT:

An answer has been deleted, so just to bring my comments back: please note that I'm talking about the MAX size, not the current size. Consider that I've researched a lot before asking the question here, so there's no need to teach the meaning of Xms, Xmx or any of the other of the parameters that specify the size of regions of the memory (those can be found elsewhere).

EDIT2:

I wrote the following simple code to test this behavior:

public static void main(String[] args) throws Exception {
  while (true) {
    final Runtime r = Runtime.getRuntime();
    System.out.println("r.freeMemory() = " + r.freeMemory()/1024.0/1024);
    System.out.println("r.totalMemory() = " + r.totalMemory()/1024.0/1024);
    System.out.println("r.maxMemory() = " + r.maxMemory()/1024.0/1024);
    Thread.sleep(1000);
  }
}

Then I ran it with -Xmx100m, -Xmx110m, -Xmx120m, etc... for many many different values, both on Sun's JVM and o JRockit. Sun's will always report a bizarre value for maxMemory() and would grow on big steps (like 30M) between runs. JRockit reported the exact value every time.

Answer 1

The `Xms` and `Xmx` only serve to indicate the minimum and maximum sizes of the allocated heap. The actual size of the allocated heap could/will be a value between the minimum and maximum, as the JVM can resize the heap, especially during object allocation events or garbage collection events.

If you need the JVM to use the "exact" heap size, you can specify Xms and Xmx values that are close enough to each other, so that heap resizing does not occur. Of course, these values must correspond to a contiguous amount of free memory.

The above section assumed something else, and can be ignored for practical purposes.

Based on the code used to calculate heap size, it should be noted that Runtime.maxMemory() returns a value that does not correspond to the value passed in the Xmx flag for the Hotspot JVM; the documentation is vague in stating that it will simply return a value that indicates the memory available for the JVM to use.

Inferring from your posted code's behavior, heap resizing will result in different values being reported for different invocations of Runtime.maxMemory(). Also, it would be needless to point out that the JRockit JVM reports the value passed in via Xmx flag.