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

[Coleen Phillimore]

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