RFR: 8311981: Test gc/stringdedup/TestStringDeduplicationAgeThreshold.java#ZGenerational timed out [v2]

[Axel Boldt-Christmas]

On Mon, 14 Aug 2023 07:36:01 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> Sorry if I didn't make it clear, as I understand the description: The VM thread will not complete the handshake until "Generation GC Thread" have completed the VM op. Even if the lock is unlocked VM thread will wait on ZCond, and "Generation GC Thread" will wait for VM thread to execute it's VM op. We may never wait for a safepoint in a handshake. Which is the reason why we can't allocate in handshake.
> 
> If "Generation GC Thread" install the new VM op to be execute, it will still wait until it have been execute. I don't see how ZCond would be released?
> 
> The "Gen GC Thread" would still be in this method "VMThread::wait_until_executed".
> 
> Is my question clearer.

The reason the handshake stalls is because the `VM_ZRelocateStartX` VM_Operation::do_operation has been executed. The gc thread should not depend on any new VM_Operation being executed. 

However maybe there is still an issue here with `process_if_requested`. As this may require the handshake lock? and this still deadlocks the `Monitor::wait` call. 

The deadlock arises from that the `VM_Operation::do_operation` has been executed, but the gc thread has not woken from `wait_until_executed` (finished it's `Monitor::wait` call) . And a handshake which triggers a relocation stall comes in in-between.

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

PR Comment: https://git.openjdk.org/jdk/pull/15240#issuecomment-1676881739