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

Thomas Stüfe thomas.stuefe at gmail.com
Sat Aug 28 06:20:19 UTC 2021


On Fri, Aug 27, 2021 at 1:17 PM Claes Redestad <claes.redestad at oracle.com>
wrote:

> First: great find!
>
>
Thanks :)


> 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.
>

I will have to do some measurements. From reading the glibc sources, I
believe malloc_trim() should be cheap if there is nothing to trim. So
periodic trims should only cost something for the first malloc_trim() call.


>
> 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.


Interesting idea, but I'm not sure I want to couple trimming to the
lifetime of JIT threads. If we change their lifetime, increase the number
of compiler threads etc, we would then affect the trimming too. Where JIT
memory consumption is concerned, the easiest would be to hook into either
compile arena destruction or into the arena chunk pool cleaner which
periodically (atm every 5 secs) cleans the chunk pool.


> 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.
>
>
I like the idea voiced in the other emails about coupling trimming with
periodic GCs. I'll have to think this through some more.

Thank you!

..Thomas


> Thanks
> Claes
>


More information about the hotspot-dev mailing list