Re: Larger GC thresholds for non-interactive Emacs

[Eli Zaretskii]

> From: Lynn Winebarger <owinebar@gmail.com>
> Date: Wed, 22 Jun 2022 19:30:20 -0400
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, Stefan Monnier 
> <monnier@iro.umontreal.ca>, 
>       Ihor Radchenko <yantar92@gmail.com>, Mattias Engdegård 
> <mattiase@acm.org>, 
>       Tim Cross <theophilusx@gmail.com>, rms@gnu.org, Alan Mackenzie 
> <acm@muc.de>, 
>       emacs-devel <emacs-devel@gnu.org>
> 
>  > I can't tell what (if any) option allows me to overrule the configure
>  > scripts decision to use sbrk instead of mmap.
> 
>  You don't want that, not on GNU/Linux systems.  We switched away of
>  sbrk and mmap for several good reasons.
> 
> Not that I don't enjoy trawling through old threads in the emacs-devel 
> archive 
> (searching for mmap led to a thread from the introduction of the portable 
> dumper),
> but it would be a lot easier if there were design notes somewhere recording
> the rationale of the decisions reflected in the current code.

We lack someone in the role of the "project historian", who would then
summarize and publish the design discussions in the form of such
notes.  Volunteers are most welcome.

> The best I can do now
> is comb through the arguments on the list (and maybe in the bug tracker?) and
> try to guess which points ended up getting reflected in the code.

A better method is to use Git logs to find when the GNU/Linux build
stopped using mmap, and then search the archives around that time.

> I will say jemalloc appears to have a lot of heap profiling bells and 
> whistles. 

AFAIU, so does glibc.  Some of them where mentioned in the discussions
you already unearthed, AFAIR.