On Wed, Jun 22, 2022 at 8:59 AM Eli Zaretskii wrote: > > From: Lynn Winebarger > > Date: Tue, 21 Jun 2022 20:01:43 -0400 > > Cc: Eli Zaretskii , Stefan Monnier < > monnier@iro.umontreal.ca>, > > Ihor Radchenko , Mattias Engdegård < > mattiase@acm.org>, > > Tim Cross , rms@gnu.org, Alan Mackenzie < > acm@muc.de>, > > emacs-devel > > > > 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.