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

Kevin Walls kevin.walls at oracle.com
Fri Dec 31 03:30:45 PST 2010


"addressable" is fine in English 8-), but perhaps simpler to say just 
"the process size limit" without stating 4g.


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



More information about the hotspot-runtime-dev mailing list