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

[olivergillespie]

On Wed, 3 May 2023 12:16:13 GMT, olivergillespie <duke at openjdk.org> wrote:

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

Thanks for the comments. Please check the updated version, it updates to have each caller pass the appropriate workers. The VMOp now grabs (and activates, as necessary) the safepoint workers instead of delegating that work, and populate can simply use the workers->active_workers as passed in (or run serially, as appropriate).

This is now a slightly more substantial change - not only are we parallelizing, but we're moving the GC-based ObjectCountAfterGC away from safepoint workers.

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

PR Comment: https://git.openjdk.org/jdk/pull/13774#issuecomment-1536120709