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

[Thomas Schatzl]

On Fri, 5 May 2023 13:05:27 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:
> 
>   Fix use of WithActiveWorkers
>   
>   My scope was incorrect, thanks @albertnetymk
>   Also fix ResourceMark usage, thanks Aleksey.

See the suggestion.

src/hotspot/share/gc/shared/gcVMOperations.cpp line 175:

> 173:     // Can't run with more threads than provided by the WorkerThreads.
> 174:     const uint capped_parallel_thread_num = MIN2(_parallel_thread_num, workers->max_workers());
> 175:     WithActiveWorkers with_active_workers(workers, capped_parallel_thread_num);

I would *almost* rely on the workgang's 'active_workers()' here because all collectors set this proportional to heap size (people tend to start 128M VMs on hundreds-of-thread machines... ). The problem is that one heap inspection VM operation. Maybe put the `WithActiveWorkers` there and use `workers->active_workers()` here?

This is just a suggestion.

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

Marked as reviewed by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13774#pullrequestreview-1415050462
PR Review Comment: https://git.openjdk.org/jdk/pull/13774#discussion_r1186256267