RFR: 8348268: Test gc/shenandoah/TestResizeTLAB.java#compact: fatal error: Before Updating References: Thread C2 CompilerThread1: expected gc-state 9, actual 21 [v2]

[Aleksey Shipilev]

On Mon, 10 Feb 2025 21:54:51 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Non-java threads were not having their gc-state configured when they attach. If they were created before the verifier's safepoint, but after the iteration over non-java threads, they would not have the correct state.
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Hold the thread lock when concurrently changing gc state

Great find. 

So that means we cannot safely do `ShenandoahHeap::set_gc_state_concurrent`, unless we hold `Threads_lock` and do a handshake afterwards? I think a part of comment that you have near `MutexLocker` can go to `ShenandoahHeap::set_gc_state_concurrent` with the `assert(Threads_lock->is_locked(), ...`.

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

PR Review: https://git.openjdk.org/jdk/pull/23428#pullrequestreview-2608045755