RFR: 8311981: Test gc/stringdedup/TestStringDeduplicationAgeThreshold.java#ZGenerational timed out [v2]
Robbin Ehn
rehn at openjdk.org
Mon Aug 14 07:21:04 UTC 2023
On Mon, 14 Aug 2023 01:32:58 GMT, David Holmes <dholmes at openjdk.org> wrote:
>> Please see the JBS issue for full details on the underlying deadlock issue (credit to @stefank for discovering it) and the proposed solution (credit @pchilano and @xmas92 ). Quite simply we make `HandshakeState::has_operation()` non-blocking by using a `try_lock` and conservatively return `true` to indicate an operation may be pending. By not blocking we avoid the deadlock scenario. All usages of the changed code have been examined to see that they are safe with this change (they all basically just take a safe slow path to see if there really is an operation).
>>
>> Testing:
>> - tiers 1-4, 7
>> - the failing string dedup test was run under our tier7 conditions, 10 times on linux-x64-debug and windows-x64-debug
>>
>> Given the nature of the deadlock this testing is not sufficient to claims success as we probably only saw 1 failure in many hundreds of runs. So if anyone has suggestions for additional testing please speak up. Otherwise we are relying on "correctness by design" - we've removed a blocking condition that leads to the 3-way deadlock, and examined the code paths affected.
>>
>> Thanks.
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>
> Fix typo
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?
-------------
PR Comment: https://git.openjdk.org/jdk/pull/15240#issuecomment-1676790440
More information about the hotspot-runtime-dev
mailing list