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

[Thomas Stuefe]

On Mon, 10 Jul 2023 14:04:33 GMT, Ashutosh Mehra <duke at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 32 additional commits since the last revision:
>> 
>>  - Make test spikes more pronounced
>>  - Dont query procfs if logging is off
>>  - rename logtag again
>>  - When probing for safepoint end, use the smaller of (interval, 250ms)
>>  - Remove TrimNativeHeap and expand TrimNativeHeapInterval
>>  - Improve comments for non-supportive platforms
>>  - Aleksey cosmetics
>>  - suspend count return 16 bits
>>  - Fix linker errors
>>  - Merge branch 'master' into JDK-8293114-JVM-should-trim-the-native-heap
>>  - ... and 22 more: https://git.openjdk.org/jdk/compare/eb3249a7...15566761
>
> src/hotspot/share/runtime/trimNativeHeap.cpp line 139:
> 
>> 137:         double t2 = now();
>> 138:         if (sc.after != SIZE_MAX) {
>> 139:           const size_t delta = sc.after < sc.before ? (sc.before - sc.after) : (sc.after - sc.before);
> 
> @tstuefe under what situations can `sc.after` be more than `sc.before` after trimming? Is it to handle the case where memory allocations happened in-between the malloc_trim() and the calls to get process memory?

Yes. The numbers we print out are RSS; there is no way to get the exact figure for how much memory has been released by the glibc (not even itself knows). RSS is influenced by many factors, and its a rough outline only.

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

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