Code Review fix for 6799919 Recursive calls to report_vm_out_of_memory are handled incorrectly
Daniel D. Daugherty
daniel.daugherty at oracle.com
Tue Feb 19 21:04:09 PST 2013
Thanks for the review!
I had previously done a code history analysis for the offending code
block as an example for Ron on how that is done in this crazy multi
source code control system we call Java... Yes, this went from Mercurial
back into TeamWare and I had to find the old rt_baseline workspace...
We'll dig it up tomorrow and attach it to the bug report along with
other analysis if needed.
On 2/19/13 9:41 PM, David Holmes wrote:
> 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
>> 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
>>> the change:
>>> 6799919: Recursive calls to report_vm_out_of_memory are handled
>>> Summary: report_vm_out_of_memory() should allow
>>> 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
>>> - regular JPRT test job is in process
>>> Comments, questions and suggestions are welcome.
More information about the hotspot-runtime-dev