RFR: 8334594: Generational ZGC: Deadlock after OopMap rewrites in 8331572

[Aleksey Shipilev]

On Thu, 20 Jun 2024 09:57:18 GMT, Erik Österlund <eosterlund at openjdk.org> wrote:

> The same comment is present for ZGC and Shenandoah where we perform safepoints. But there the situation is typically the exact opposite to what the comment suggests then. Since we perform concurrent root scanning, we are just about to use the oop map cache, and the placement is probably the most unfortunate instead. It seems like we clean the caches just before using them instead just after. But again, that seems like a follow-up thing.

Yeah, we did it out of symmetry with other (STW) GC ops. We can actually move these around to the exact places in Shenandoah and ZGC right after concurrent root handling happens. Relaxing the requirement for actually locking ServiceLock with this particular fix would help safety when we move the trigger around.

(Re phasing: at least for Shenandoah, the start-update-refs op would start soon after root processing and evac is over, so we get the _after_ effect as well. There might be additional contention on reclamation queue and GlobalCounter that we can avoid, though).

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

PR Comment: https://git.openjdk.org/jdk/pull/19800#issuecomment-2180325904