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

[Bengt Rutisson]

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

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

Bengt

> Thanks,
>
> JohnC
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20130312/e0e2bbc8/attachment.htm>