GNU bug report logs - #45200
Wishlist: There should be a `malloc-trim' function

Previous Next

Full log

View this message in rfc822 format

From: Konstantin Kharlamov <hi-angel <at> yandex.ru>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: carlos <at> redhat.com, martin rudalics <rudalics <at> gmx.at>, dj <at> redhat.com, fweimer <at> redhat.com, 45200 <at> debbugs.gnu.org
Subject: bug#45200: [PATCH] Force Glibc to free the memory freed
Date: Wed, 03 Feb 2021 18:29:41 +0300

On Wed, 2021-02-03 at 10:15 -0500, Stefan Monnier wrote:
> > Stefan, what do you think? Will it be okay if I implement a patch that runs
> > `malloc_trim(0)` when Emacs is idle?
> 
> That's yet another reason why we should provide that function to ELisp,
> and then have ELisp decide when it's called (whether after GC, or on
> idle or what).

Okay, let's discuss this idea. It seems that running `malloc_trim(0)` on idle (let's say, after 10 seconds of idling, which implies a user might have switch to a browser, or something) should resolve all performance concerns. Especially given, measurements show it has pretty negligible impact even when located on return from GC.

To answer you question in another email about memory benefits given default Emacs settings: well, today I tried creating a testcase that would reproduce problem with default settings, but haven't really succeeded at it. I have a testcase where Emacs without the patch has ≈20M more memory than the one with the patch, but that's pretty small difference, and offhand I didn't manage to get it increased any further.

So, I'm thinking of wiring the functional of memory trimming to on-idle hook, without possibility to disable it. Given how small performance impact in this case would be, I see no reason to even implement an option to disable it.

Thoughts?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.