misc catchup

[Doug Lea]

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

While I'm at it, a quick digression on all the Encounter Order
posts: I confess to not understanding "encounter order".
I understand bulk op semantics on random-access data structures --
arrays and associative arrays (i.e., ConcurrentHashMaps), which
is why I focus on them.
Everything else seems to be a matter of consensus interpretation.
I understand that everyone wants parallel ops to work on structures
besides arrays and hash maps, and I am happy to live with Brian's
attempts to make as much sense of them as possible and have the least
sucky performance as possible. But both of these concerns will always
be relative. (And one reason not to complain too much is that the
Scala folks did approximately the same things and don't seem to
regret it yet :-)

-Doug