Re: Should use of mallopt depend on DOUG_LEA_MALLOC?

[Eli Zaretskii]

> Cc: Noam Postavsky <address@hidden>, address@hidden
> From: Paul Eggert <address@hidden>
> Date: Fri, 13 Dec 2019 13:55:36 -0800
> 
> On 12/13/19 7:22 AM, Stefan Monnier wrote:
> > For those in `init_alloc_once_for_pdumper`, I can't help you.
> 
> Those mallopt calls shouldn't be needed.

Can you elaborate why?

And if that's indeed true, then what is our response to reports such
as the one in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38345#71 ?
I thought a judicious use of mallopt would allow us to come close to
jemalloc, but if not, then what would?  Assuming what Ihor Radchenko
sees and is reported in that discussion is normal operation of glibc's
malloc, don't we want to be able to return memory to the OS more
eagerly than the default malloc configuration does?

> Proposed patch attached. The basic idea is to use "#ifdef M_MMAP_MAX" 
> instead of "#ifdef DOUG_LEA_MALLOC" to decide whether to call mallopt 
> with M_MMAP_MAX. Plus, stop fiddling with mallopt parameters that are 
> problematic given that glibc malloc has mutated so much (and is likely 
> to mutate further).

Thanks, but let's postpone such cleanups until after the release
branch is cut (hopefully soon).  I would like to leave the
unexec-related code in its current form for Emacs 27.1, and only fix
any bugs that will be reported against it.