Request for review (and comments) 6302804: Hotspot VM dies ungraceful death when C heap is exhausted in various places. (original) (raw)

Coleen Phillimore coleen.phillimore at oracle.com
Mon Jan 3 10:44:41 PST 2011

On 12/31/2010 6:30 AM, Kevin Walls wrote:

"addressable" is fine in English 8-), but perhaps simpler to say just "the process size limit" without stating 4g. Yes, this seems simpler. Thank you. On 29/12/2010 23:57, Vladimir Kozlov wrote: Coleen,

Everything looks good. One thing, in solutions instead of "the 4g process size" should be something general since on windows we have only 2Gb. May be "In 32 bit mode, the addressable memory size limit was hit" ^ I am not sure about my English here. Thanks, Vladimir!

Coleen

Thanks, Vladimir

Coleen Phillimore wrote: Summary: enhance the error reporting mechanism to help user to fix the problem rather than making it look like a VM error.

I've incorporated the comments that I've received and have a new webrev. open webrev at http://cr.openjdk.java.net/~coleenp/63028042/ bug link at http://bugs.sun.com/viewbug.do?bugid=6302804 Thanks, Coleen On 12/22/2010 7:44 PM, Vladimir Kozlov wrote: Sorry for noise - it was JDK bug.

I found that the problem was with previous JDK with build > 99: 6994413: JDKGetVersionInfo0 only expects a two digit build number This bug was fixed in b118 JDK. So when we used before jdk7-b107 for JPRT it had this bug. Latest JPRT builds (which uses latest jdk) does not have this problem: # JRE version: 7.0-b122 # Java VM: OpenJDK 64-Bit Server VM (20.0-b04-internal-201012221004.ct232829.7007377-fastdebug compiled mode solaris-sparc compressed oops) Thanks, Vladimir

Coleen Phillimore wrote: On 12/22/2010 6:20 PM, Vladimir Kozlov wrote: Coleen, Could you also fix "JRE version: 7.0" output to print full JRE version (as with -version) since you are touching this code? Actually, I tried to do this when I implemented this the first time. If I remember correctly, most of the text from -version comes from the JDK and the only bit of the version I could find from the VM was in vmversion(), which was just this number. Because it was in error handling, I didn't want to add a callback to the jdk (or call one if it already existed). Coleen Thanks, Vladimir Vladimir Kozlov wrote: Coleen,

Could you use "Out of swap space" in "No swap to commit thread stack"? With these changes next output: # # A fatal error has been detected by the Java Runtime Environment: # # java.lang.OutOfMemoryError: requested 32764 bytes for ChunkPool::allocate. Out of swap space? # # Internal Error (C:\temp\jprt\P1\B\213124.ap31282\source\src\share\vm\memory\allocation.cpp:181), pid=17396, tid=14008 # Error: ChunkPool::allocate # # JRE version: 7.0 # Java VM: OpenJDK Server VM (20.0-b03-internal-201012142131.ap31282.hotspot-g1-push-fastdebug mixed mode windows-x86 ) # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # Will be converted to next. Right? # There is insufficient native memory for the Java Runtime Environment to continue. # Attempting to allocate XXX bytes for mmm. malloc failed. # # JRE version: 7.0 # Java VM: OpenJDK Server VM (20.0-b03-internal-201012142131.ap31282.hotspot-g1-push-fastdebug mixed mode windows-x86 ) Could you swap next lines to be consistent with non oom errors?: 325 if (id != oomerror) { 326 st->printcr("#"); to: 325 st->printcr("#"); 326 if (id != oomerror) {

Instead of next: # There is insufficient native memory for the Java Runtime Environment to continue. # Attempting to allocate XXX bytes for mmm. malloc failed. how about this?: # There is insufficient native memory for the Java Runtime Environment to continue: # malloc failed to allocate XXX bytes for mmm. Also may be add comma at the end of solution lines. An other solution is to use 64bit VM on 64bit OS. Thanks, Vladimir coleen phillimore wrote: Summary: enhance the error reporting mechanism to direct user to fix the problem rather than making it look like a VM error. I changed the error reporting so that out of swap and out of native (C heap) memory doesn't look like a VM assert or look like a java.lang.OutOfMemoryError exception that someone could catch. The suggested new wording is in the bug link Evaluation section. I'm open to rewording if people have strong preferences. Also, if solaris runs out of swap space (generally by filling up /tmp), access to thread stacks generate a bus error with ENOMEM errno. I can check for this in the solaris signal handler and give the out of C heap message. I couldn't get Linux or windows to fail the same way, so didn't apply similar changes there. open webrev at http://cr.openjdk.java.net/~coleenp/6302804/ bug link at http://bugs.sun.com/viewbug.do?bugid=6302804 Thanks, Coleen

More information about the hotspot-runtime-dev mailing list