JDK-4505762 : memMax() lies and causes OutOfMemoryError if used
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 1.4.0
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,windows_98,windows_2000
  • CPU: generic,x86
  • Submitted: 2001-09-21
  • Updated: 2006-02-02
  • Resolved: 2006-02-02
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
1.4.2 mantisFixed
Related Reports
Duplicate :  
JDK-4700099 - JRE1.4.0: maxMemory() returns wrong value in applet
Relates :  
JDK-6960437 - max-heap-size greater than maxMemory(
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
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mantis FIXED IN: mantis INTEGRATED IN: mantis
14-06-2004
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.
11-06-2004
WORK AROUND Name: gm110360 Date: 09/21/2001 Supply "Xmx" argnument with options to args[] and use it instead of runtime.maxMemory() ======================================================================
11-06-2004
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.
11-06-2004