RFR: 8308043: Deadlock in TestCSLocker.java due to blocking GC while allocating [v2]
Erik Österlund
eosterlund at openjdk.org
Tue May 16 11:51:39 UTC 2023
> The TestCSLocker.java test spawns a thread that grabs the GC locker, and then wait for the first thread to run some java code and then get signal back to release the GC locker. All of this while another thread is allocating garbage and triggering GCs. Naturally, if the thread that is to signal the release of the GC locker requires GC in order to make progress, we will end up with a deadlock that leads to a timeout. As it turns out, that does indeed happen. A println statement is performed, which in its internal implementation performs an allocation, which requires GC. I think any GC can spuriously fail here, but it seems more likely with generational ZGC for whatever reason. While it seems really shady to wait with the GC locker held while a Java thread executing Java code is supposed to make progress, in general, I think the test can be fixed by removing the println statement causing the allocation. I have run the test 200 times, and it's no longer failing with generational ZGC.
Erik Österlund has updated the pull request incrementally with one additional commit since the last revision:
Review feedback
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/13989/files
- new: https://git.openjdk.org/jdk/pull/13989/files/c4124a0f..c410aed9
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=13989&range=01
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=13989&range=00-01
Stats: 7 lines in 2 files changed: 4 ins; 2 del; 1 mod
Patch: https://git.openjdk.org/jdk/pull/13989.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/13989/head:pull/13989
PR: https://git.openjdk.org/jdk/pull/13989
More information about the hotspot-gc-dev
mailing list