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

[Bruno Félix Rezende Ribeiro]

Eli Zaretskii <address@hidden> writes:

>> From: Bruno Félix Rezende Ribeiro <address@hidden>
>> Cc: Dmitrii Korobeinikov <address@hidden>,  address@hidden
>> 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/>

signature.asc
Description: PGP signature