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. This pull request has now been integrated. Changeset: 68da02c7 Author: Alan Bateman <al...@openjdk.org> URL: https://git.openjdk.org/jdk/commit/68da02c7b536799ccca49e889c22f3e9a2691fb7 Stats: 154 lines in 2 files changed: 148 ins; 0 del; 6 mod 8292240: CarrierThread.blocking not reset when spare not activated Reviewed-by: dfuchs ------------- PR: https://git.openjdk.org/jdk/pull/9841
