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

Albert Mingkun Yang ayang at openjdk.org
Fri Sep 15 14:58:49 UTC 2023


On Thu, 14 Sep 2023 14:40:56 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

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

OK, maybe `set_young_collection_default_active_worker_threads` and/or its surrounding logic could be revised. It suggests that the number of workers can vary for each young GC, while predictors assume that the number of workers is constant. Just a cursory remark on this preexisting inconsistency, as my initial understanding was that a predictor tracks time/work-unit per thread, rather than time/work-unit per N threads.

Yes, it's a separate issue.

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

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


More information about the hotspot-gc-dev mailing list