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

John Cuthbertson john.cuthbertson at oracle.com
Tue Mar 12 10:08:31 PDT 2013

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

New webrev soon.



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

More information about the hotspot-gc-dev mailing list