Interaction between virtual threads and ForkJoinPool.commonPool

[Levi Aul]

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? 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?