[8u] RFR 8249846: Change of behavior after JDK-8237117: Better ForkJoinPool behavior

[Martin Balao]

Hi David,

Thanks for proposing this fix.

On 8/18/20 4:10 PM, David Alvarez wrote:
> During the backport of JDK-8237117 a regression was added that affected
> how the DefaultForkJoinWorkerThreadFactory works. The idea was to change
> the context for threads in the commonPool, but it ended up affecting the
> threads in all pools created with that factory. This patch decouples the
> commonPool from the DefaultForkJoinWorkerThreadFactory
> 
>   Bug: https://bugs.openjdk.java.net/browse/JDK-8249846
>   Webrev:
> http://cr.openjdk.java.net/~alvdavi/webrevs/8249846/webrev.8u.jdk.00/
> 
> My original intention when writing the patch was to make the CommonPool
> use the InnocuousForkJoinWorkerThreadFactory [1] in all cases,
> regardless of whether a SecurityManager is installed or not, as we are
> already creating threads with an innocuous AccessControlContext for
> commonPool threads even when there is no SecurityManager installed.
> However, the InnocuousForkJoinWorkerThreadFactory creates
> InnocuousForkJoinWorkerThreads [2], which have some more nuances, like
> the erase of ThreadLocal variables or avoid setting an
> UncaughtExceptionHandler. I was afraid of introducing more regressions
> with this change (in fact, one jtreg test [3] did fail because it was
> setting an uncaught exception handler), that is why I decided to go for
> a new factory (DefaultCommonPoolForkJoinWorkerThreadFactory) that mimics
> current behavior, even if it means the behavior of the common pool if a
> SecurityManager is installed during initialization is still not the same
> as if the SecurityManager is installed after initialization.

I suggest to continue this discussion in the context of the
Vulnerability Group.

Thanks,
Martin.-