RFR: Parallel safepoint cleaning

[Roman Kennke]

I realized that my former attempt to parallelize safepoint cleaning (or
rather, idle monitor deflation) was a complete fail (have you seen a
workers->run_task() call anywhere?). Also, I realized that we can't
(ab)use GC worker threads either: SP cleaning can kick in in the middle
of conc marking/evac/uprefs, and we can't use GC workers when they're
working (and no, we don't stop our GC workers at non-GC safepoints, as
opposed to all other GCs).

So I completely rewrote the whole thing. I gave SafepointSynchronize its
own worker pool with default size 8 (just a guess). I added a flag
-XX:+ParallelSPCleanup to enable parallel SP cleaning and
-XX:ParallelSPCleanupThreads=X to specify number of threads.

I also added some hooks to let the GC tell the safepoint machinery that
it would like to take over monitor deflation and/or nmethod marking.
This makes sense because both of those cleanup passes iterate+scan over
the thread stacks, and if the GC is scanning it anyway, we can just as
well piggy-back on it and benefit from better caching, parallelization,
etc. This can be enabled separately by -XX:+ShenandoahSPCleanup (and can
be mixed with or without parallel cleanup).

Piggybacking deflation and nmethod-marking should always be benefitial
or at least not adversarial.

Parallelizing cleanup work in general is only benefitial with large
numbers of threads and/or excessive inflated monitors. I have seen quite
some overhead to spin up the parallel fluff, and need to investigate it
a little more (watch out for changes in the init-UR pause, this is
basically a no-op and bound by SP cleanup work).

http://cr.openjdk.java.net/~rkennke/par-sp-cleaning/webrev.01/
<http://cr.openjdk.java.net/%7Erkennke/par-sp-cleaning/webrev.01/>

I intend to upstream the non-Shenandoah parts soon.

Testing: hotspot_gc_shenandoah, specjvm

Ok?

Roman