RFR: Parallelize safepoint cleanup

[Roman Kennke]

Hi David,

the patch applied cleanly, i.e. was not affected by any hotspot changes.
Most of your suggestions applied to the GC part that I excluded from the
scope of this change, except for the following:

>> I introduced a dedicated worker thread pool in SafepointSynchronize.
>> This is only initialized when -XX:+ParallelSafepointCleanup is enabled,
>> and uses -XX:ParallelSafepointCleanupThreads=X threads, defaulting to 8
>> threads (just a wild guess, open for discussion. With
>> -XX:-ParallelSafepointCleanup turned off (the default) it will use the
>> old serial safepoint cleanup processing (with optional GC hooks, see
>> below).
>
> I think the default needs to be ergonomically set, as for other
> "thread pools". Both flags should be experimental at this stage.

I implemented this using the following:

  if (ParallelSafepointCleanup &&
FLAG_IS_DEFAULT(ParallelSafepointCleanupThreads)) {
    // This will pick up ParallelGCThreads if set...
    FLAG_SET_DEFAULT(ParallelSafepointCleanupThreads,
Abstract_VM_Version::parallel_worker_threads());
  }

As noted, it will pick up ParallelGCThreads, which might be a reasonable
number. Otherwise we'd need to re-work the logic in vm_version.cpp to
calculate the number of worker threads without considering
ParallelGCThreads.

http://cr.openjdk.java.net/~rkennke/8180932/webrev.02/
<http://cr.openjdk.java.net/%7Erkennke/8180932/webrev.02/>

What do you think?

Roman