RFR: JDK-8293114: JVM should trim the native heap [v7]
Thomas Stuefe
stuefe at openjdk.org
Mon Jul 10 13:54:27 UTC 2023
On Mon, 10 Jul 2023 13:38:50 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:
>> 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.
It was arbitrarily chosen to have a higher chance of "slipping" in between safepoints for larger trim intervals, but not be too small to save CPU. Admittedly I thought about this less time that this sentence takes writing.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/14781#discussion_r1258304917
More information about the serviceability-dev
mailing list