CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
mantis

FIXED IN:
mantis

INTEGRATED IN:
mantis


                                     

SUGGESTED FIX

###@###.### 2002-07-31

Changed JVM_MaxMemory to return the maximum amount of memory likely to
be available for 'normal' java objects, which more closely matches
JVM_TotalMemory.  The value is computed by a new method
CollectedHeap::max_capacity(); the name parallels the implementation
of JVM_TotalMemory, which returns CollectedHeap::capacity().

Cleanups:  fix some potential 64-bit overflow bugs in the JVM_*Memory entry
points (returning size_t as a jlong), made a few accessor methods const,
and removed the TraceMaxHeapCapacity flag and associated methods.

Diffs attached.
                                     

WORK AROUND



Name: gm110360			Date: 09/21/2001


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

EVALUATION

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

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