RFR(S): 8009536: G1: Apache Lucene hang during reference processing

Bengt Rutisson bengt.rutisson at oracle.com
Tue Mar 12 15:10:50 PDT 2013

Hi John,

On 3/12/13 6:08 PM, John Cuthbertson wrote:
> Hi Bengt,
> Thanks for looking at the changes.
> On 3/12/2013 8:05 AM, Bengt Rutisson wrote:
>> Hi John,
>> Thanks for fixing this so quickly!
> The main change is based upon your patch. It just took a little time 
> to evaluate and disregard the alternatives (as well as fix the 
> underlying problems they discovered).
>> I have only had a quick look at the change. I'll make sure to look 
>> closer tomorrow. However, I have two questions. If you have time to 
>> answer them it would be good. If you don't have time I hope they 
>> become clear when I look more in detail at the change tomorrow...
>> First, in the constructor for G1CMDrainMarkingStackClosure() we do:
>> 2285     _do_stealing = !_is_serial;
>> 2286     _do_termination = true;
> Yes we can. I had thought of that but I thought people wouldn't like it.

I think I would prefer a single _is_serial or even _is_par instance 

>> Just from looking at this it seems like we could get away with only 
>> having one instance variable instead of three. Is that the case or 
>> can any of _do_stealing, _is_serial or _do_termination change during 
>> the life time of a G1CMDrainMarkingStackClosure instance?
>> Second, as you describe in the text below you are actually fixing two 
>> issues with this patch. Would it make sense to split the changes up 
>> into two changesets?
> OK. That's probably a good idea as long as the second gets in fairly 
> soon - the Lucene tests will fail with an assertion failure when 
> parallel reference processing is enabled, if the overflows occur at 
> just the right points. I'll split them up into adding the serial path 
> to do_marking_step followed by the changes for the assertion failure.

Great, thanks! I think we can push the changes at the same time. It is 
just much easier to review one thing at a time.

> New webrev soon.

:) Looking forward to it!


> Thanks,
> JohnC

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20130312/e0e2bbc8/attachment.html 

More information about the hotspot-gc-dev mailing list