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

[Vladimir Kozlov]

Sorry for noise - it was JDK bug.

I found that the problem was with previous JDK with build > 99:
6994413: JDK_GetVersionInfo0 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 
> vm_version(), 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 != oom_error) {
>>>  326       st->print_cr("#");
>>>
>>> to:
>>>
>>>  325     st->print_cr("#");
>>>  326     if (_id != oom_error) {
>>>
>>>
>>> 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/view_bug.do?bug_id=6302804
>>>>
>>>> Thanks,
>>>> Coleen
>>>>
>>>
>>>
>