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

[Kim Barrett]

On Thu, 22 Sep 2022 07:08:08 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> src/hotspot/share/gc/g1/g1Policy.cpp line 1124:
>> 
>>> 1122:   uint remaining = target - MIN2(target, full);
>>> 1123:   size_t bytes = remaining * HeapRegion::GrainBytes;
>>> 1124:   return bytes - MIN2(bytes, allocator->used_in_alloc_regions());
>> 
>> From what I can tell it's only this last line that require the `Heap_lock` to be held, so we could still do an estimate (slightly worse) even if we fail to take the lock. So my question is would it make sense to move the `Heap_lock->try_lock()` in here and just skip including `allocator->used_in_alloc_regions()` in the calculation when not getting the lock?
>
> `_g1h->young_list_count()` and `young_list_target_length()` can also be
> changed, protected by `Heap_lock`.

Also, I originally didn't include the used_in_alloc_regions information in the calculation, and the resulting predictions were pretty bad, esp. with larger region sizes.

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

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