[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Bruno Félix Rezende Ribeiro
Subject: Re: Garbage collector: is 800kb a good default?
Date: Fri, 10 Apr 2020 15:26:49 -0300
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)

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]


[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]

Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]