FJP::setParallelism update

[Dan Heidinga]

> > The new method is ::setParallelism(int) [0].  Once the crac branch
> > consumes the latest jdk stream, I'll update FJP to implement Resource
> > and we can update the parallelism so pools, in particular the common
> > pool, work better when the available # of threads changes.
> >
> > [0] https://github.com/openjdk/crac/blob/f235955eefb1141a2e72116dfcf345e40416f059/src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java#L2938
>
> Are you going change the common pool behavior or all instances of FJP?
> Or all instances of FJP with the default parallelism value? I think we
> need carefully avoid changing parallelism of a FJP if that was set
> explicitly.

Definitely the common pool as it's managed by the JVM (though we won't
change it if the parallelism has been set by env var).

For other pools, I'm not sure what the right behaviour is yet. They
would have been tuned based on the # of processors of the machine they
were running on prior to the checkpoint. After the checkpoint, if
we're running on a different machine or have a different share of the
# of processors, then previous tunings - even if explicit - are likely
wrong.

We could develop an adjustment factor: abs(prevCPUs - currentCPUs))
and apply that to each pool in an attempt to preserve user intent, but
it may be better to have users directly update their pools.  This
would be a great use for Volkier's "snapsaftey" concept if we could
treat use of a FJP as a warning/error that moved up the call stack and
either prevented checkpointing or was addressed by someone who
implemented Resource.

Some of this will depend on looking at FJP usage to see how deeply
embedded it is into applications.  Do users have control to tune these
usages? Is it mainly driven by libraries / frameworks tuning to # of
cpus?  Lots to look at here.

--Dan

>
> Thanks,
> Anton
>