RFR: 8137022: Concurrent refinement thread adjustment and (de-)activation suboptimal [v2]

[Kim Barrett]

On Thu, 22 Sep 2022 13:28:40 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:
>> 
>>  - lengthen some names
>>  - improve comments for primary do_refinement_step
>>  - add is_pending_cards_target_initialized
>
> src/hotspot/share/gc/g1/g1ConcurrentRefine.cpp line 238:
> 
>> 236:                               predicted_thread_buffer_cards,
>> 237:                               goal_ms);
>> 238:   if (_thread_control.max_num_threads() == 0) {
> 
> I'd expect it to be non-zero if `G1UseConcRefinement == true`.

One can set -XX:G1ConcRefinementThreads=0, and just let the mutator threads do
refinement.  There's a known problem that mutator threads won't "catch up" if
there is more refinement work to be done than the refinement threads can
manage, which of course is the case if there aren't any refinement threads.
https://bugs.openjdk.org/browse/JDK-8293616

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

PR: https://git.openjdk.org/jdk/pull/10256