Increment WorkQueue.blockingTasksInBuffer only after capacity check (#3569)
Otherwise, it is possible to leave dangling blockingTasksInBuffer increment that will never be decremented back, leading to unnecessary full-scans on any attempt to steal only blocking task.
This change does not have a corresponding unit-test because it fixes the performance regression that is not observable semantically
diff --git a/kotlinx-coroutines-core/jvm/src/scheduling/WorkQueue.kt b/kotlinx-coroutines-core/jvm/src/scheduling/WorkQueue.kt
index 0a93265..611f2b1 100644
--- a/kotlinx-coroutines-core/jvm/src/scheduling/WorkQueue.kt
+++ b/kotlinx-coroutines-core/jvm/src/scheduling/WorkQueue.kt
@@ -83,8 +83,8 @@
* `null` if task was added, task that wasn't added otherwise.
*/
private fun addLast(task: Task): Task? {
- if (task.isBlocking) blockingTasksInBuffer.incrementAndGet()
if (bufferSize == BUFFER_CAPACITY - 1) return task
+ if (task.isBlocking) blockingTasksInBuffer.incrementAndGet()
val nextIndex = producerIndex.value and MASK
/*
* If current element is not null then we're racing with a really slow consumer that committed the consumer index,
