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

[Alan Bateman]

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