RFR(S): 8009536: G1: Apache Lucene hang during reference processing
John Cuthbertson
john.cuthbertson at oracle.com
Tue Mar 12 17:08:31 UTC 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.
Thanks,
JohnC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20130312/303f7e07/attachment.htm>
More information about the hotspot-gc-dev
mailing list