On Thu, 11 Aug 2022 16:11:02 GMT, Alan Bateman <al...@openjdk.org> wrote:
> 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. It took me some time to figure out why -1 was different than 0 but now I see it. If `FJP.beginCompensatedBlock()` returned 0 then `ct.beginBlocking()` would have been called, but `ct.endBlocking()` would not be called. LGTM ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.org/jdk/pull/9841
