Interaction between virtual threads and ForkJoinPool.commonPool

[Alan Bateman]

On 06/10/2021 02:34, Levi Aul wrote:
> I have some work projects that have third-party-lib dependencies which
> schedule background work by creating ForkJoinTasks, and then explicitly
> submitting those ForkJoinTasks to the ForkJoinPool.commonPool. These
> background workloads in turn do blocking IO; and so (with high-enough
> concurrency) they end up blocking the whole set of ForkJoinPool.commonPool
> worker threads for long periods, resulting in awful latencies as other
> quick tasks scheduled to the commonPool never start.
>
> I'm looking into Loom's virtual threads to solve this problem. But, from
> what I've read so far, the Loom changes by themselves don't seem to do
> anything to "enhance" or "co-opt" the ForkJoinPool.commonPool, and so won't
> be of much help in my situation.
>
> Is this correct, or have I missed something?
That is correct, the FJP common pool works as before.


> Is it possible under the
> Loom-branch JVM to configure the ForkJoinPool.commonPool to act as a dumb
> proxy for a VirtualThreadExecutor, such that tasks run against the
> commonPool get unbounded IO concurrency? Or is it even unnecessary (i.e. do
> *all* ForkJoinPools in Loom park their ForkJoinTasks when they hit
> low-level runtime blocking-yield-points, such that all ForkJoinTasks are
> equivalent to "virtual threads" in behavior, even if the ones that are
> explicitly ForkJoinTasks have no associated isVirtual=true Thread object)?
>
> Also, to clarify: if a CompletableFuture/Callable/etc. is scheduled onto a
> Loom virtual thread (which is running on a ForkJoinPool-based scheduler),
> is that workload then implicitly running in the scope of a ForkJoinTask,
> such that it has a thread-local reference to its (carrier thread's)
> ForkJoinPool, such that calls that implicitly schedule "through" that
> reference if available (e.g. stream().parallel()) will schedule as Loom
> virtual threads? Or do these just end up using the ForkJoinPool.commonPool
> as well?
If code executing in a virtual thread uses stream parallel() or 
CF.xxAsync then the tasks run in the common pool as before (or the CF 
default executor if overridden). Yes, this is area that needs further 
attention and exploration. There was some discussion about it early on 
but it was kicked down the road to give time to figure out the 
programming model and core implementation. So I expect it will come back.

-Alan