RFR: 8169423: Infinite loop in G1's ConcurrentMarkThread
thomas.schatzl at oracle.com
Wed Nov 16 08:44:13 UTC 2016
On Tue, 2016-11-15 at 19:11 -0500, Kim Barrett wrote:
> > On Nov 15, 2016, at 5:11 AM, Thomas Schatzl <thomas.schatzl at oracle.
> > com> wrote:
> > Hi,
> > On Fri, 2016-11-11 at 15:38 -0500, Kim Barrett wrote:
> > >
> > > Please review this fix of a potential (though quite rare)
> > > infinite
> > > loop in G1's concurrent mark thread's service routine.
> > >
> > > CR:
> > > https://bugs.openjdk.java.net/browse/JDK-8169423
> > >
> > > Webrev:
> > > http://cr.openjdk.java.net/~kbarrett/8169423/webrev.00/
> > >
> > > Testing:
> > > JPRT
> > looks good.
> > It would be nice to have some information about during which phase
> > the concurrent mark stack overflowed. This seems out of scope
> > though, I created JDK-8169706.
> Agreed. Thanks for filing that.
> I had originally guessed mark_from_roots might loop on overflow, but
> I don’t see any sign of that.
Any attempt to push oops on the mark stack can overflow, setting the
The overflow handling during concurrent mark is inlined in
G1CMTask::do_marking_step(), the message hidden in
[What happens is that the concurrent mark threads are synchronized, and
the marking retried - without even trying to expand the mark stack
(printing "Concurrent Mark reset for overflow").
That's a decision that should be revisited, since it seems that mark
stack overflow seems to be a "common issue". JDK-8057003 should provide
relief in 9 by avoiding mark stack overflow in many cases. There is
some other CR to think about the policy again.]
> The duplicative debug logging message that I removed was certainly
> suggestive of that, explicitly saying the restart is because of
> overflow “in Remark”.
Yeah. I was thinking of asking you about the removal of the duplicate
messages at different log levels, but then I thought that it would be
nice to look at these messages again anyway.
More information about the hotspot-gc-dev