Re: Garbage collector: is 800kb a good default?

["Bruno Félix Rezende Ribeiro" <oitofelix@gnu.org>]

[-- Attachment #1: Type: text/plain, Size: 1434 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Bruno Félix Rezende Ribeiro <oitofelix@gnu.org>
>> Cc: Dmitrii Korobeinikov <dim1212k@gmail.com>,  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]
<http://oitofelix.freeshell.org/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]