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

olivergillespie duke at openjdk.org
Wed May 3 12:16:13 UTC 2023


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

olivergillespie has updated the pull request incrementally with one additional commit since the last revision:

  Use ParallelGCThreads instead of active_workers

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13774/files
  - new: https://git.openjdk.org/jdk/pull/13774/files/22b9b6d5..711cb643

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13774&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13774&range=02-03

  Stats: 9 lines in 1 file changed: 1 ins; 7 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


More information about the hotspot-gc-dev mailing list