He-Pin commented on issue #661: URL: https://github.com/apache/pekko/issues/661#issuecomment-4940399188
Investigation update (2026-07-11): I re-tested the old `externalSubmit` yielding POC from `fork/fjyield` (`8cad2b196d`) against JDK 21 and JDK 25. Results: - JDK 21.0.5: `ForkJoinPoolStarvationSpec` passed (1 test, 1000 ping/reply iterations, 46 ms). - JDK 25.0.2: the same POC failed twice, timing out after about 3 seconds waiting for `All fine`. - Instrumentation on JDK 25 confirmed that the POC really called `ForkJoinPool.externalSubmit`: the pool's submission count increased after each throughput-boundary resubmission and the steal count kept increasing. This rules out reflection/version detection or a fallback to ordinary `execute` as the cause. The JDK 25 failure is a second fairness problem. `externalSubmit` moves the resubmitted mailbox from a worker-local queue to a shared submission queue, but it does not guarantee fairness between different submission queues. With two continuously replenished queues and parallelism 2, each worker can remain attached to one busy queue indefinitely while the innocent actor's submission queue is never visited. This matches the still-unresolved OpenJDK report [JDK-8373224](https://bugs.openjdk.org/browse/JDK-8373224), which describes workers continuously stealing from replenished external queues while other external queues starve. The original local-vs-external starvation regression is [JDK-8315740](https://bugs.openjdk.org/browse/JDK-8315740), resolved as `Won't Fix`. `externalSubmit` was added in JDK 20 and only guarantees placement into a submission queue; it does not specify cross-queue fairness ([JDK-8297648](https://bugs.openjdk.org/browse/JDK-8297648)). Conclusion: - The POC can make this exact test pass on JDK 21.0.5, but that is not a portable fairness guarantee. - On JDK 25.0.2, `externalSubmit` alone is not sufficient. - JDK 17-19 do not expose `externalSubmit`; relying on reflective access to private `externalPush` plus `--add-opens` would not be an acceptable library/runtime contract. - Keeping this spec pending on JDK 17+ is currently the safest option if Pekko retains the existing `ForkJoinPool` architecture. Removing the skip robustly would require an architectural change under Pekko's control, such as a centralized external handoff queue/thread for throughput-boundary yields, or using a fairer executor. That would change a hot scheduling path and needs benchmarks, shutdown/race coverage, and broader dispatcher regression testing; it should not be treated as a test-timeout fix. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
