RFR: 8137022: Concurrent refinement thread adjustment and (de-)activation suboptimal [v3]
Kim Barrett
kbarrett at openjdk.org
Mon Sep 26 13:23:27 UTC 2022
On Sun, 25 Sep 2022 12:43:43 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:
>> Kim Barrett has updated the pull request incrementally with three additional commits since the last revision:
>>
>> - wanted vs needed nomenclature
>> - remove several spurious "scan"
>> - delay => wait_time_ms
>
> src/hotspot/share/gc/g1/g1Analytics.cpp line 251:
>
>> 249: double G1Analytics::predict_dirtied_cards_in_thread_buffers() const {
>> 250: return predict_zero_bounded(_dirtied_cards_in_thread_buffers_seq);
>> 251: }
>
> I believe this sequence captures #dirty cards in thread buffers at GC pause start. However, I don't think it follows a normal distribution because of the buffer-size clamping. In comparison, the dirty-cards-generation-rate (`predict_dirtied_cards_rate_ms`) more likely follows a normal distribution.
The number of dirty cards in thread buffers at the start of GC pause is
exactly what this is supposed to capture. We discount the number of cards that
can be processed in the budgeted time by this prediction to get the target
number of cards in the queue. It's not a very accurate prediction, but it's
still worth doing. For some applications and configurations I've tested (with
low G1RSetUpdatingPauseTimePercent) it might be 5-10% of the target. A model
based on the number of threads tends to do very poorly for some applications.
This is entirely different from predict_dirtied_cards_rate_ms, which is a
different value and has different uses.
> src/hotspot/share/gc/g1/g1ConcurrentRefine.cpp line 339:
>
>> 337: }
>> 338: Atomic::store(&_threads_wanted, new_wanted);
>> 339: _dcqs.set_max_cards(mutator_threshold);
>
> Preexisting: `set_mutator_threshold` is probably more precise.
Agreed. s/max_cards/mutator_refinement_threshold/, and tweaked a few comments. Will be in the next push.
-------------
PR: https://git.openjdk.org/jdk/pull/10256
More information about the hotspot-dev
mailing list