RFR: 8300915: G1: incomplete SATB because nmethod entry barriers don't get armed [v4]

Richard Reingruber rrich at openjdk.org
Thu Jan 26 15:08:18 UTC 2023


On Thu, 26 Jan 2023 11:20:35 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> > In that case, I think there is still the same issue for case 4. If a CM is
> > aborted because we are interrupting an old CM in order to start a new CM, then
> > we still have a case where we have an old marking cycle that has finished, but
> > not successfully. We can't call
> > G1CollectedHeap::finish_codecache_marking_cycle() until we have successfully
> > marked through all objects in the heap. If we were to call that when an old CM
> > is aborted, then is_unloading() might start returning true on nmethods that
> > were on-stack in some loom continuation object in the old generation. This was
> > the main point of only conditionally starting cycles - then the epoch counters
> > being marked in the nmethods would be conservative and potentially keep
> > nmethods around a bit longer that really could be discarded.
> 
> That's a very good point I didn't see and didn't get it from the comment I removed.
> 
> On the other hand: do we ever call is_unloading() on nmethods without a complete marking cycle?

I see now: we do indeed e.g. in `CodeBlobIterator::next_impl()`.

So I'm beginning to think we should do the conservative/minimal fix mentioned in
the pr description above: just arm nmethod entry barriers unconditionally in the initiating YC pause before the
concurrent marking.

-------------

PR: https://git.openjdk.org/jdk/pull/12194


More information about the hotspot-gc-dev mailing list