RFR: JDK-8293114: JVM should trim the native heap [v7]

[Aleksey Shipilev]

On Mon, 10 Jul 2023 12:27:44 GMT, Thomas Stuefe <stuefe at 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