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

[Erik Österlund]

On Thu, 26 Jan 2023 15:05:40 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.
> 
> 

Right. Thomas is assuring me though that case 4 no longer exists. If that's the case, then my worries all vanish.

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

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