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

Thomas Stuefe stuefe at openjdk.org
Mon Jul 10 12:36:16 UTC 2023


On Mon, 10 Jul 2023 10:37:18 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Add test with 1ms trim interval
>>  - No need for atomics
>
> src/hotspot/share/runtime/globals.hpp line 1990:
> 
>> 1988:           "If TrimNativeHeap is enabled: interval, in ms, at which "        \
>> 1989:           "the to trim the native heap.")                                   \
>> 1990:           range(1, UINT_MAX)                                                \
> 
> I have a suggestion that simplifies UX, I think. In other cases where we do these kinds of intervals, we just use `0` as the "off" value. See for example `AsyncDeflationInterval`, `GuaranteedSafepointInterval`. This would allow users to supply one option only. 
> 
> We would then need to decide if we turn this thing on by default (probably with large interval), or we default to `0` for "off". I would prefer to go for `0`. I understand that would force users to decide on proper trim interval when enabling, but I think that's a feature, not a bug. We would not have to go into discussions if the 60 second default is good enough or not.
> 
> Something like this:
> 
> 
>   product(uintx, TrimNativeHeapInterval, 0, EXPERIMENTAL,                   \
>           “Attempt to trim the native heap every so many milliseconds, “    \
>           “if platform supports it. Lower values provide better footprint “ \
>           “under native allocation spikes, while higher values come with “  \
>           “less overhead. Use 0 to disable trimming.”                       \

Makes sense. I was afraid of people shooting themselves in the foot if not presented with a sensible default, but you are right we have precedence with similar switches.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14781#discussion_r1258185263


More information about the serviceability-dev mailing list