RFR: JDK-8293114: GC should trim the native heap [v9]

[Thomas Stuefe]

On Tue, 7 Feb 2023 20:30:45 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> Thanks for working on this. I'm still thinking about it.

Thanks :)

The PR is currently in Draft, I did not expect people to care. Its almost finished, but the description is outdated. I really don't like that Skara sends out mails for draft-state PRs. I consider closing this PR for the moment to avoid this.

> 
> A question, could we also have a option for trimming on/after GC iff RSS is above settable threshold? (with some nice logic that pushes threshold upwards if RSS is still higher after trim)

Sure, that makes sense.

In our VM, we have a warning system that triggers automatically at certain RSS thresholds. You tie arbitrary jcmds to those thresholds, and customers use that to do a System.trim_native_heap jcmd. So, its certainly possible.

I only dislike that this is tied to GC. Depending on the GC, if none runs, you may never hit the threshold. But I'll add this to my run-alongside-GC trigger loop.

> 
> Secondly do you have any performance numbers regarding throughput/latency when trimming is on vs off?

I tried before and got nothing raising from background noise; I guess the trim cycle is just to long (I had a 30 second cycle).

I will repeat the tests. What benchmark would you recommend? I also plan to do a regular benchmark but with an agent lib injected that does concurrent malloc spikes, to mimic third party code doing mallocs on the side.

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

PR: https://git.openjdk.org/jdk/pull/10085