RFR: 8030815: Code roots are not accounted for in region prediction [v2]

[Thomas Schatzl]

On Thu, 14 Sep 2023 13:37:02 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> src/hotspot/share/gc/g1/g1Policy.cpp line 904:
>> 
>>> 902:                                        average_time_ms(G1GCPhaseTimes::OptCodeRoots);
>>> 903: 
>>> 904:       _analytics->report_cost_per_code_root_scan_ms(avg_time_code_root_scan / total_code_roots_scanned, is_young_only_pause);
>> 
>> It's kind of a preexisting issue -- it's super weird to see `avg_time / total_count`; `sum_time / total_count` is more reasonable. The current calculation assumes the same number of gc-workers is used for each gc-pause, I believe.
>
>> sum_time / total_count is more reasonable
> 
> doesn't account for work done in parallel.

Long time ago the assumption has been made that the number of threads is fairly constant over time. This assumption is still in effect.

Since number of threads is dependent on heap size, which is typically fairly constant and large (the heuristics is something like 1 thread per 64MB of heap size*) there is not much difference in many/most applications given typical thread assignments.
Another problem when varying threads is that often work does not scale with number of threads too for various reasons. Then there is the question what to optimize for: g1 as a STW collector for obvious reasons prefers to use the maximum amount of threads (that is useful) to minimize pauses anyway. Generally speaking there is not much point (given that goal) to use less threads than available except to avoid scaling bottlenecks.

(There is often not much cpu time to save too given the gc time spent in pauses compared to the mutator)

Something to discuss seperately from this issue :)

(* that heuristic also has obvious flaws)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15632#discussion_r1326062233