On Mon, 10 Jul 2023 12:27:44 GMT, Thomas Stuefe <stu...@openjdk.org> wrote:
>> src/hotspot/share/runtime/trimNativeHeap.cpp line 106:
>>
>>> 104: ml.wait(wait_ms);
>>> 105: } else if (at_or_nearing_safepoint()) {
>>> 106: ml.wait(safepoint_poll_ms);
>>
>> OK, so here is a little problem. Suppose I want to run trims very often,
>> like every 10ms. This loop would stall for 250ms when safepoint is detected,
>> which throws off this guarantee. Can we instead go and sleep for
>> `TrimNativeHeapInterval`? AFAICs, this plays nicely with heuristic guidance
>> (short intervals -> more interference), and it would best-effort stall for
>> twice the interval when safepoint interjects.
>
> But then we have a problem for larger trim intervals. Loosing one or multiple
> trim attempts because a safepoint happened to happen hurts if the interval is
> e.g. 5 minutes.
>
> We could either wait for `MIN2(TrimNativeHeapInterval, safepoint_poll_ms)`.
>
> Or, at the cost of one Mutex grab per safepoint, I could do a `notify_all()`
> at the end of a safepoint.
Yes, waiting for `MIN2(TNHI, <reasonable-higher-limit>)` would be my
preference. Not sure how 250ms was chosen, probably to be slightly above
`MaxGCPauseMillis`? Should document the reasoning a bit.
Let's not grab more mutexes during safepoint. This is opportunistic feature, we
should not risk deadlock/longer safepoints.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/14781#discussion_r1258282439
