Eli Zaretskii writes: >> From: Bruno Félix Rezende Ribeiro >> Cc: Dmitrii Korobeinikov , emacs-devel@gnu.org >> Date: Fri, 10 Apr 2020 11:26:36 -0300 >> > On GNU/Linux, Emacs doesn't really return malloc'ed memory to the >> > system, so once the memory footprint grows, it more or less stays that >> > way even after GC. >> Really? Why is that? > Because that's how malloc/free are implemented in glibc. I’m surprised to find this out and I’m surprised that the GNU system overall behaves like that (because its C library does). How is that not a practical problem? Sometimes I deal with very large buffers, and it’s not uncommon to have an Emacs uptime of more than a month. This explains what I thought were memory leaks: Emacs progressively eating large chunks of memory and eventually leading my machine to die out of starvation.[1] Can’t we use an alternative allocator that do return freed memory?[2] Footnotes: [1] Not good for my dreams of using a perpetual Lisp machine. [2] IIRC, I read somewhere that the OpenBSD one does. I wonder if this and the GC behavior in general has something to do with Emacs being very slow and unresponsive there. It’s a Lemote YeeLoong, but Emacs worked fine there on GNU/Linux. -- Bruno Félix Rezende Ribeiro (oitofelix) [0x28D618AF]