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

[Robbin Ehn]

On Mon, 14 Aug 2023 07:25:17 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> > Hello, a question, if I understand the description correctly: Even if "Generation GC Thread" gets the VM op lock, it will still wait for VM thread to execute it's VM op. But if the VM thread is blocked in the handshake waiting for that VM op, we are still stuck?
> > What I'm I not understanding?
> 
> In `Monitor::wait()` the `InFlightMutexRelease` is used by `ThreadBlockInVMPreprocess` to unlock the lock before calling `SafepointMechanism::process_if_requested`.

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.

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

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