JDK-4697804 : VM should minimize need for calls to vm_exit_out_of_memory()
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version:
    1.3.1_07,1.4.0,1.4.1,1.4.1_01,1.4.1_02,1.4.2 1.3.1_07,1.4.0,1.4.1,1.4.1_01,1.4.1_02,1.4.2
  • Priority: P4
  • Status: Closed
  • Resolution: Other
  • OS:
    generic,solaris_7,solaris_8,solaris_9,windows_2000 generic,solaris_7,solaris_8,solaris_9,windows_2000
  • CPU: generic,x86,sparc
  • Submitted: 2002-06-05
  • Updated: 2012-10-03
  • Resolved: 2012-10-03
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.
JDK 6
6 b81Resolved
Related Reports
Duplicate :  
JDK-4816658 - Crash - Unexpected Signal : 10 occurred at PC=0xFA493DE4
Relates :  
JDK-4317486 - [sol/c1/b04] assert generation.cpp 469 during scavenge.
Relates :  
JDK-4432433 - javadoc run in build on linux crashes jvm (gnumake all docs)
Relates :  
JDK-6405799 - JVM Exits with OutOfMemoryError for vm\utilities\growableArray.cpp
Relates :  
JDK-4719001 - all collectors should implement Generation::commit_contiguous_available
Description
--------------------------------------
Test         : nsk/regression/b4432433
TestBase        : testbase_nsk 
VM              : server , client
Mode            : comp . mixed
Platform (s)	: solx86 , rh7.2
----------------------------------------

Error output (for solx86)
sh std-doit.sh
/net/alpheridies/export/VM/hopper/weekly/JDK/latest/solx86/bin/java -client -DHA
NGINGJAVA -client -Xmixed -Xmx1024m b4432433 1024

Exception java.lang.OutOfMemoryError: requested 1048592 bytes
Status = 1
------------------------------------------------
/net/alpheridies/export/VM/hopper/weekly/JDK/latest/solx86/bin/java -client -DHA
NGINGJAVA -client -Xcomp -Xmx1024m b4432433 1024

Exception java.lang.OutOfMemoryError: requested 1048592 bytes
Status = 1
------------------------------------------------
/net/alpheridies/export/VM/hopper/weekly/JDK/latest/solx86/bin/java -server -DHA
NGINGJAVA -server -Xmixed -Xmx1024m b4432433 1024

Exception java.lang.OutOfMemoryError: requested 28835840 bytes
Status = 1
------------------------------------------------
/net/alpheridies/export/VM/hopper/weekly/JDK/latest/solx86/bin/java -server -DHA
NGINGJAVA -server -Xcomp -Xmx1024m b4432433 1024

Exception java.lang.OutOfMemoryError: requested 28835840 bytes
Status = 1
------------------------------------------------
***** Please Note*******
This has been reported since 1.4.1-beta-b06. THe information was added to an exiting bug b4432433. Since that bug was already in Integrated state when this additonal comment was added, not sure if this is getting tracked. Hence
Opening a new bug for better tracking
************************************
Steps to reproduce:
----------------------
1. cd /net/sqesvr.eng/export/vsn/GammaBase/Bugs/{BugID}
2. sh doit.sh


###@###.### 2002-06-05


###@###.### 2003-04-24

In the past, we have seen VM exits that appeared
to be due to running out of memory (no OutOfMemory
exception - just a VM exit).  A little digging on this
led us to the following bug report:

http://developer.java.sun.com/developer/bugParade/bugs/4697804.html

The specific problem described in this bug that concerns us
is the potential for the VM to simply exit when it can't
expand the heap, rather than throw an OutOfMemory exception
that would allow the application to continue and/or recover.

We are doing our best to work around this by following the
recommended practices of configuring enough swap and setting
-Xms equal to -Xmx.  Unfortunately we can't really control our
customers swap configurations (can only make recommendations) and
so we feel compelled to use the Xms = Xmx workaround which is
really inefficient in many cases.
###@###.### 10/27/04 21:58 GMT
Comments
Been in resolved state for more than ten years. Closing.
03-10-2012
EVALUATION CR 6405799 concerns object marking code which can sometimes cause a vm_exit_out_of_memory() if there is not enough swap space to expand the C-heap. This code currently uses more space for better performance but is being examined to determine if less space can be used without too large a loss of performance. If a reasonable tradeoff can be reached, a change regarding that CR will fix an instance of calling vm_exit_out_of_memory() not previously identified.
24-04-2006
SUGGESTED FIX The fix for 2) is being integrated for mustang b81.
10-04-2006
SUGGESTED FIX Promotion failure handling is on by default in 1.6.0.
14-03-2006
EVALUATION Adding some of the explanations in the JDC comments. Q. Could you change the implementation to use data structures of a fixed size, pre-allocated so that errors just send you back to a known state? A. Regarding the comment about using pre-allocated fixed size data structures to avoid the problem of the JVM not being able to get additional memory during a garbage collection, the garbage collector does use pre-allocated data structures. However, there are data structures that may need space that is proportional to the amount of live data in the heap. It is very unusual that this actually occurs so space is not pre-allocated for this contingency (because such pre-allocated space would not be available to the application). Rather a fixed amount of space is pre-allocated and more is requested only in the rare situations where it is actually needed. Also there are a few situations where the JVM has requested that the operating system reserve space for the JVM and when the space is actually needed, it is not available. Q. How about simply releasing the jvm memory consumed and returning to a fresh state so it can continue servicing new calls and throw a error for existing processes that were consuming memory. A. Regarding the comment from the respondent, if I understand correctly, you are asking if an out-of-memory can be sent only to the thread that is consuming memory and resulted in the JVM calling vm_exit_out_of_memory(). As relates to 4697804 the JVM is trying to get memory so that it can complete a garbage collection. As such there is no free space in the Java heap so that any request for the allocation of an object from any thread would fail. The JVM could release all its ancillary data structures but that doesn't change the fact that the Java heap needs to be collected.
09-03-2006
SUGGESTED FIX 1- Remove print statement from os_win32.cpp's os::commit_memory 2- Remove call to vm_exit_out_of_memory from DefNewGeneration::compute_new_size() 3- (this is the more difficult one) Pre-commit memory needed by the old generation to satisfy the full promotion guarantee. Note that this is only needed by young generation collections which do not implement a "promotion-undo" (e.g. collectors which will leave the heap in an unknown state if promotion fails for an reason). ###@###.### 2002-07-11 1) has already been fixed. 2) need to work on this 3) will be fixed when we turn on promotion failure handling in all the collectors. ###@###.### 2005-2-07 18:08:06 GMT
07-02-2005
EVALUATION Sometimes when the VM is in a low-resource situation, it currently cannot throw an OutOfMemory error because the heap is corrupt -- no further Java code can run. This often happens when we're trying to expand the heap and cannot successfully malloc space for the supplemental data structures that we need. When this happens, the VM prints OutOfMemory and exits (cleanly, rather than with a fault). (see bug 4317486 [sol/c1/b04] assert generation.cpp 469 during scavenge.) We should try to ensure we can never get into such a state by atomically allocating all data that we require, so we can roll-back to a consistant heap state. I haven't yet found where exactly we're calling vm_exit_out_of_memory for this test case (and it might change from machine to machine, depending on how many resources we have)... but doing so might give us a good place to start cleaning this up. Please note that in typical use, users are not trying to provoke OutOfMemory exceptions. If they hit this condition, they'd see an indication of what went wrong, e.g. Exception java.lang.OutOfMemoryError: requested 1048592 bytes and the VM will exit. This at least indicates a possible solution (bumping -Xmx and perhaps -Xms). This doesn't help deployed Java applications, though, that might catch the OutOfMemory error and more robustly handle the situation, so anything changes we can make to allow the error to be thrown would be useful. ###@###.### 2002-06-06 The customer test case from the JDC comments shows one of the scenarios where we can exit the VM: when we're attempting to resize the heap after a GC and cannot get enough resources to do so. Growing the heap is actually implemented as a multi-step process, as we also grow supporting data structures for the heap. Ideally, if one of these steps fail we should roll back to a known good heap state. I'm looking into how to do that for the mantis time frame. Note there are other failure modes which also need to be looked at. ###@###.### 2002-07-08 Committing to fix the most common causes of this problem for Mantis, 1.4.2. ###@###.### 2002-07-11 Further work showed us that while fixing the common cause of this, we just moved the problem: typically we'd still get unrecoverable errors and there was simply nothing Java code could do to attempt to clean up. This is a very difficult problem to solve. We are working on some possible solutions, but our best suggestion for users running into this problem is to avoid the problem by increasing swap space on their machines so they have enough to cover the Java application's needs plus all other applications running on the machine at the same time. ###@###.### 2002-08-29 ###@###.### 2005-2-04 19:22:49 GMT
29-08-2002
WORK AROUND Disable VM heap resizing by setting -mx and -ms to the same value. This will prevent us from hitting the most common sources of the vm_exit_out_of_memory exits. ###@###.### 2002-07-11 The best thing to do is increase swap size on the machines encountering this error. ###@###.### 2003-01-30
11-07-2002