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

[Kim Barrett]

On Sat, 24 Sep 2022 14:24:54 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/g1ConcurrentRefine.cpp line 97:
> 
>> 95:     }
>> 96: 
>> 97:     if (UseDynamicNumberOfGCThreads) {
> 
> I actually think failing-early is more desirable if the requested number of threads can't be satisfied. Semi-related, when `UseDynamicNumberOfGCThreads == true`, thread-allocation-failure has diff consequence depending whether it's in start-up or not -- such discrepancy incurs some complexity in the code.

Sorry, I don't think I'm understanding the first part of the comment. We can't
know at startup whether we can allocate the threads if we don't allocate them
at startup. And we don't want to allocate them unless/until we need them.

The difference in behavior for startup vs later for thread allocation failure
is intentional, and not new to this change.  That was discussed back when
support for lazy thread creation was added.  If not being lazy, then hard fail
if allocation fails.  If being lazy, report but try to continue without the
additional thread(s).

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

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