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

Thomas Schatzl tschatzl at openjdk.org
Thu Jan 26 15:52:25 UTC 2023


On Thu, 26 Jan 2023 15:40:30 GMT, Erik Österlund <eosterlund at openjdk.org> wrote:

> > I do think the problem exists with case 2) undone end (no CM needed in the end).
> > `CodeCache::_gc_epoch` is incremented before the YC and with the current version of the pr again when the CM start is undone after YC at the same safepoint. This can happen a couple of times and is_unloading() might start returning true on nmethods in loom StackChunks. That would be not good as they do have frames.
> 
> Isn't it the case though that the CM is undone because the YC already visited all the objects? Then when the _gc_epoch is 

The reason why the CM is undone because the heap occupancy after gc is lower than the threshold to start the initial marking at the end of gc.
The undo has nothing to do with having visited a certain set of objects.

> incremented at the end where we call the undo hook, the implication is that we have finished the full collection, and hence nmethods that haven't been marked as maybe on-stack, can't be on-stack (virtually or physically). That assumption seems to hold true, since the YC traversed all the stack chunks in the young generation, and there aren't any in the old generation. Or is there a situation where we undo, even though there is more than one object in the old generation that we have not visited?

The undo does not take (and never took) whether objects have been visited or not or whether there are stack chunks in the old generation into account. It makes that decision purely on heap occupancy.

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

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


More information about the hotspot-gc-dev mailing list