New default for ForkJoinPool.commonPool on systems with SecurityManagers

[Doug Lea]

[Cross-posting on core-libs-dev and concurrency-interest.]

The ForkJoinPool common pool is used in JDK8 for
all parallel Stream operations, parallel sorting, etc.
When designing this, we knew that in some managed environments,
administrators might want to limit or disable parallelism,
so we support a way to do so using system property
java.util.concurrent.ForkJoinPool.common.parallelism.

But we hadn't provided a way to allow only "innocuous" parallelism;
performed by worker threads that are happy to help sort
data etc, but cannot do anything (like open a file) that
needs a Permission. We allowed people to create a special
ForkJoinWorkerThreadFactory and use for the default via property
java.util.concurrent.ForkJoinPool.common.threadFactory.
But it is not at all easy for people running Java EE and other
managed platforms to define a suitable factory.

So we added an extra-conservative safe-out-of-the-box default:
If not already overridden by system properties,
and a SecurityManager is present, the default is now
to use instances of an internal (non-public)
InnocuousForkJoinWorkerThread class. Each worker
has no Permssions set, is not a member of any user-defined
ThreadGroup, and erases all ThreadLocals after running
any externally-submitted task.

Thanks especially to Chris Hegarty and Alan Bateman for helping
to figure out what "innocuous" should entail.

Even though it is running very late in the release process,
this seems like such a good idea that we hope to get it
in for JDK8. The internal mechanics to  support this currently
require  quite a lot of encapsulation breakage.
Someday we might want to try to generalize the idea of
innocuous threads in a way that could be more tastefully supported.

This is currently committed in 166 CVS, and Chris Hegarty will
soon put out a webrev for OpenJDK.

This support was also added to the jsr166e version so people can
also experiment with it even if not yet able to use JDK8.
Although I believe that this will only work if jsr166e.jar
is in bootclasspath.

Also note that extra-paranoid and/or mean-spirited
administrators can still disable all parallelism.

-Doug