Proposal: On Linux, add option to periodically trim the glibc heap

[Claes Redestad]

First: great find!

On 2021-08-27 11:05, Thomas Stüfe wrote:
> We could add to this logic VM-internal knowledge, but I am not sure if that
> complexity is warranted since we never can reliably guess the future
> allocation behavior of both VM and non-VM code:
> - trimming when (big) arenas are released or when the arena pool is cleaned
> out
> - trimming periodically, but not if a certain number ofos::malloc  calls
> happened in the recent past
> - trimming if the delta between current and peak allocation is X
>     (would require NMT to be always on)
> 
> What do you think?

Doing it periodically is simple and straightforward, but I guess it
could affect GC latency negatively, and by doing it repeatedly when
there's no need to is likely harmful to tail end latencies.

Assuming a significant part of this excess memory was allocated by JIT
threads that got spun up during startup/warmup and then terminated when
there was less work, trimming after a drop in such threads (with some
grace time) might be a simple yet effective heuristic. No need to track
os::malloc calls or allocation rate with NMT that way. I think doing the
same for GC threads might be less attractive, since those threads are
more likely to be revived periodically and more stable over time.

Thanks
Claes