java version "1.4.0-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-beta-b65)
Java HotSpot(TM) Client VM (build 1.4.0-beta-b65, mixed mode)



java -Xmx128m MemTest

(alloc byte[16*1024] until OutOfMemory to see what memory status says...)
  From Runtime:
maxMem: 201326592 totalMem:133955584 freeMem:8068624,  used:125886960 (62%)
exit due to OutOfMemoryError while alloc (~16k).

This reveals that there is not only a diffrence to maxMem but that the maxMem
has not been reached by far. The only limit that we are close to is the declared
command option (128m). So even though max is not equal to "Xmx" (due to VM
difference that is tollerable)  the OutOfMemory seems to connected to the
original "Xmx" value. This is not a workable environment.
(Review ID: 132340) 
======================================================================
Posted Date : 2006-02-02 19:25:05.0

Supply "Xmx" argnument with options to args[] and use it instead of
runtime.maxMemory()
======================================================================

  xxxxx@xxxxx   2002-06-27

From the eval of duplicate bug 4700099:

	Mark says that "the rough intent" was to return the value of -Xmx, 
	though that's not what the spec says.  What we are returning is 
	the "reserved" space for the heap, which includes a survivor 
	space and the permanent generation that are part of the collected 
	heap, but not available for Java objects.

	We should just return _max_heap_size or MaxHeapSize, or maybe 
	the max of those.

	  xxxxx@xxxxx   2002-06-11

From a brief conversation with Peter:

maxMemory() should return (an approximation of) the memory that is
usable for 'normal' objects, and should not include the extra space needed by
the garbage collector (e.g., an extra survivor space) and should not include
the permanent generation.