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