RFR: 8307348 - Parallelize heap walk for ObjectCount(AfterGC) JFR event collection

[olivergillespie]

ObjectCount(AfterGC) event does a full single-threaded heap scan at a safepoint. After https://bugs.openjdk.org/browse/JDK-8215624, it is trivial to use the parallel version of the heap scan, reducing the time spent at the safepoint, and thus reducing the overhead of this event.

The performance improvement is obvious, but just for confirmation, on my 16-core host, at around 1GB occupancy:


Before: 770ms ( [3.059s][debug][gc,phases         ] GC(13) Report Object Count 770.317ms )
 After:  92ms ( [2.335s][debug][gc,phases         ] GC(13) Report Object Count  91.742ms )


Question 1: Should this be the default behaviour for populate_table (use the number active workers as the parallelism, if nothing else specified)?

Question 2: Is active_workers the correct value to use here? Or is max_workers more appropriate?

-------------

Commit messages:
 - 8307348 - Parallelize heap walk for ObjectCount(AfterGC) JFR event collection

Changes: https://git.openjdk.org/jdk/pull/13774/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13774&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8307348
  Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13774.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13774/head:pull/13774

PR: https://git.openjdk.org/jdk/pull/13774