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
