Code Review fix for 6799919 Recursive calls to report_vm_out_of_memory are handled incorrectly
david.holmes at oracle.com
Tue Feb 19 20:41:49 PST 2013
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. ;-)
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.
> On 20/02/2013 9:48 AM, Daniel D. Daugherty wrote:
>> I'm sponsoring this code review request from Ron Durbin. This change
>> is targeted at JDK8/HSX-25 in the RT_Baseline repo.
>> I have a proposed fix for the following bug:
>> 6799919 Recursive calls to report_vm_out_of_memory are handled
>> 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
>> 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:
>> - See the READ_ME file attached to the JDK-6799919 for the gory
>> 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.
More information about the hotspot-runtime-dev