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

[Kim Barrett]

On Tue, 27 Sep 2022 12:12:05 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>>> A zero value for the prediction indicates that we don't have a valid
>> prediction
>> 
>> Why not? It's still possible that the alloc-rate is zero after start-up; I mean alloc-rate is up to applications.
>> 
>> On a related note, there's special treatment for too-close upcoming GC pause later on, `if (_predicted_time_until_next_gc_ms > _update_period_ms) {`. Shouldn't there be sth similar for too-far upcoming GC pause? IOW, `incoming_rate * _predicted_time_until_next_gc_ms;` would be unreliable for farther prediction, right?
>
>> Why not? It's still possible that the alloc-rate is zero after start-up; I mean alloc-rate is up to applications.
> 
> Allocation rate is the rate of allocation between GCs, to have a GC, you (almost) need non-zero allocation rate (not with periodic gcs).

I've added some comments regarding the alloc_bytes_rate == 0 case.

I don't think we need to do anything special for predicted GC times being far
away, because we'll be periodically re-evaluating.

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

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