misc catchup

[Brian Goetz]

> As most of you probably probably surmised from
>  http://cs.oswego.edu/pipermail/concurrency-interest/2012-October/010182.html
> implicit use of the ForkJoinPool.commonPool can/should replace
> the internal ForkJoinUtils in lambda builds. Besides being easier
> to use, and reducing resource use when people are otherwise
> tempted to create their own "default" pools, it exploits knowledge
> of the pool to improve execution times, In particular, fjt.invoke()
> will often be faster than FJP.invoke(fjt); moreso when people use
> some new idioms (including those I've thought of and probably more.)

As soon as we have this merged, we'll migrate our implementation.  

> As usual, I've been using ConcurrentHashMap to explore maximal
> customized bulk op performance (using extremely specialized
> tasks). Using it with commonPool leads to a nicer API and
> better performance.

Hopefully ditto for streams.