On Mon, 10 Jul 2023 13:38:50 GMT, Aleksey Shipilev <sh...@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
