RFR: 8292240: CarrierThread.blocking not reset when spare not activated

[Daniel Fuchs]

On Thu, 11 Aug 2022 16:11:02 GMT, Alan Bateman <alanb at 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