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

[Vladimir Kozlov]

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 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/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
>>>>>>
>>>>>
>>>>>
>>>
>