RFR: 8292240: CarrierThread.blocking not reset when spare not activated
Alan Bateman
alanb at openjdk.org
Fri Sep 9 12:57:16 UTC 2022
Some blocking operations that pin a virtual thread to its carrier will compensate by activating a spare carrier (essentially managed blocker). This is done by wrapping the operation in a Blocker begin/end. This code is not correct for the case that a spare cannot be activated (e.g. already at the max of 256 carrier threads). When that happens, the carrier thread's "blocking" flag, used to detect reentrancy, is not reset when the blocking operation is done. The result is that subsequent blocking operations by virtual threads on this carrier thread will not attempt to activate a spare.
The test runs with parallelism=1 and maxPoolSize=2 in order to make it easier to create the conditions for this bug.
-------------
Commit messages:
- Adjust comments
- Merge
- Merge
- Merge
- Initial commit
Changes: https://git.openjdk.org/jdk/pull/9841/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9841&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8292240
Stats: 154 lines in 2 files changed: 148 ins; 0 del; 6 mod
Patch: https://git.openjdk.org/jdk/pull/9841.diff
Fetch: git fetch https://git.openjdk.org/jdk pull/9841/head:pull/9841
PR: https://git.openjdk.org/jdk/pull/9841
More information about the core-libs-dev
mailing list