Code Review fix for 6799919 Recursive calls to report_vm_out_of_memory are handled incorrectly

[David Holmes]

Okay full disclosure. :) I filed this bug back in 2009 so I undoubtedly 
ran into a failure where this guard was causing the useful error 
information to be lost, and so I filed the bug.

Now I am so much older and wiser I'm wondering about the original reason 
for the guard again. ;-)

David

On 20/02/2013 2:23 PM, David Holmes wrote:
> The one-reporter only logic in report_and_die has been there for a very
> long time, pre-dating the addition of the check in
> report_vm_out_of_memory. So I have to wonder what prompted the inclusion
> of that guard originally? No doubt there was some failure case where we
> were getting recursive errors that just totally broke the error reporting.
>
> So while I can give this the Reviewer's tick if still needed. I suspect
> that this will be a case of fixing one specific example, but in the
> process potentially breaking others.
>
> David
>
> On 20/02/2013 9:48 AM, Daniel D. Daugherty wrote:
>> Greetings,
>>
>> I'm sponsoring this code review request from Ron Durbin. This change
>> is targeted at JDK8/HSX-25 in the RT_Baseline repo.
>>
>> Dan
>>
>>
>> I have a proposed fix for the following bug:
>>
>>      6799919 Recursive calls to report_vm_out_of_memory are handled
>> incorrectly
>>      http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6799919
>>      https://jbs.oracle.com/bugs/browse/JDK-6799919
>>
>> This is one of those bug fixes where the commit message nicely describes
>> the change:
>>
>> 6799919: Recursive calls to report_vm_out_of_memory are handled
>> incorrectly
>> Summary: report_vm_out_of_memory() should allow VMError.report_and_die()
>> to handle multiple out of native memory errors.
>> Reviewed-by: dcubed, <other-reviewers>
>> Contributed-by ron.durbin at oracle.com
>>
>> Here is the webrev URL:
>>
>> http://cr.openjdk.java.net/~dcubed/for_rdurbin/6799919-webrev/0-hsx25
>>
>> Testing:
>>     - See the READ_ME file attached to the JDK-6799919 for the gory
>> details
>>       of the testing needed to reproduce this failure and verify the fix
>>     - regular JPRT test job is in process
>>
>> Comments, questions and suggestions are welcome.
>>
>> Ron