RFR: 8305903: Deflate monitors of dead objects before they become unreachable

[Kim Barrett]

On Wed, 3 May 2023 05:45:33 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> > Why do we need to fix the header of a dead object?  It's dead.  Who cares what's in the header?  Nobody should
> > be touching dead objects.  Yes, I know there is heap walking stuff that does that, which is arguably a bug.  If its a
> > choice between fixing that or doing something like this, well, I'd really like to not do this.
> 
> Hmm ok, what choice do we have? In Lilliput we synchronize GC threads with the monitor deflation handshake (which I am also going to upstream ASAP). Given that it is the G1 refinement thread that heap-walks dead objects with monitors, I guess it may be possible to let the refinement thread join the STS around heap walking and thus block deletion of monitors until it's done. I'm not totally sure if that'd work or even if that is feasible (how much time does G1 refinement spend in heap walking? Would it block monitor deflation for too long? What if monitors got deflated right before we start walking? Etc)

The "heap walk" I was referring to was things like the heap dumper and such.
As already explained, concurrent refinement shouldn't be looking at dead objects.

The concurrent refinement threads already do their work within STS, leaving it
to yield when requested, or to wait for work. But relying on STS to block
concurrent refinement doesn't work, since JavaThreads may also do refinement
work, and they of course don't use STS.

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

PR Comment: https://git.openjdk.org/jdk/pull/13721#issuecomment-1532664044