United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-4505762 memMax() lies and causes OutOfMemoryError if used
JDK-4505762 : memMax() lies and causes OutOfMemoryError if used

Details
Type:
Bug
Submit Date:
2001-09-21
Status:
Closed
Updated Date:
2006-02-02
Project Name:
JDK
Resolved Date:
2006-02-02
Component:
hotspot
OS:
generic,windows_98,windows_2000
Sub-Component:
gc
CPU:
x86,generic
Priority:
P4
Resolution:
Fixed
Affected Versions:
1.4.0
Fixed Versions:
1.4.2 (mantis)

Related Reports
Duplicate:
Relates:

Sub Tasks

Description
Name: gm110360			Date: 09/21/2001


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) 
======================================================================

                                    

Comments
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.
                                     
2004-06-11
WORK AROUND



Name: gm110360			Date: 09/21/2001


Supply "Xmx" argnument with options to args[] and use it instead of
runtime.maxMemory()
======================================================================
                                     
2004-06-11
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.
                                     
2004-06-11
CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
mantis

FIXED IN:
mantis

INTEGRATED IN:
mantis


                                     
2004-06-14



Hardware and Software, Engineered to Work Together