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

[Coleen Phillimore]

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/6302804_2/
bug link at http://bugs.sun.com/view_bug.do?bug_id=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: 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
>>>>>
>>>>
>>>>
>>