Re: Larger GC thresholds for non-interactive Emacs

[Eli Zaretskii]

> From: Lynn Winebarger <owinebar@gmail.com>
> Date: Tue, 21 Jun 2022 20:01:43 -0400
> Cc: Eli Zaretskii <eliz@gnu.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>
> 
> For some reason, the configure script chooses not to use mmap for malloc.

The configure script chooses not to use mmap directly because glibc's
malloc already does that internally where it decides that to be
beneficial, and because using mmap directly has some disadvantages
we'd like to avoid if possible.

> jemalloc is designed to use mmap as much as possible

So is glibc.

> so it isn't limited to freeing only the uppermost regions.

Neither is glibc, although it uses different algorithms.

> 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.

> Are there any formal memory-allocation/reclamation benchmarks that I should
> use instead of this ad hoc task?

Not that I know of.