emacs-devel
[Top][All Lists]
Advanced

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

Re: Larger GC thresholds for non-interactive Emacs


From: Lynn Winebarger
Subject: Re: Larger GC thresholds for non-interactive Emacs
Date: Wed, 22 Jun 2022 19:30:20 -0400

On Wed, Jun 22, 2022 at 8:59 AM Eli Zaretskii <eliz@gnu.org> wrote:
> 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.

Wow, so it is - when I tried the same test without jemalloc, both 28.1 and 24.3 gave
similar results.  I must have misinterpreted the behavior of edebug's trace-buffer as
being similar to issues I've had previously (probably due to not using an explicit 
garbage-collect,  or killing rather than deleting text with undo disabled).
Maybe I just buried the trace buffer instead of killing it.

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

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

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

 

reply via email to

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