Re: Should use of mallopt depend on DOUG_LEA_MALLOC? (WAS: bug#38345)

[Eli Zaretskii <eliz@gnu.org>]

> From: Noam Postavsky <npostavs@gmail.com>
> Date: Fri, 13 Dec 2019 07:12:09 -0500
> 
> >> Looks like mallopt is still there, but Emacs' DOUG_LEA_MALLOC code
> >> depends on malloc_set_state and malloc_get_state which were removed in
> >> glibc 2.25 (2017).
> >> https://sourceware.org/ml/libc-alpha/2017-02/msg00079.html
> >
> > Thanks.  Then I don't understand why our calls to mallopt are
> > conditioned on DOUG_LEA_MALLOC.  What they are supposed to do should
> > be good for modern glibc versions as well.
> 
> It could be just accidental, since DOUG_LEA_MALLOC (i.e.,
> malloc_get_state & malloc_set_state) used to always come with mallopt.
> Although it looks like most of the mallopt calls are only done if
> mmap_lisp_allowed_p returns false.  mmap_lisp_allowed_p is only defined
> for DOUG_LEA_MALLOC, so I'm not sure what that condition should evaluate
> to if DOUG_LEA_MALLOC is not defined.

I think the fact that mmap_lisp_allowed_p is only defined when
DOUG_LEA_MALLOC is just the consequence of its being used under that
condition.  IOW, someone tried to reduce the memory footprint by
#ifdef'ing away functions that aren't use otherwise.  I see nothing in
mmap_lisp_allowed_p that is specific to Doug Lea malloc per se.

> I also don't really have any idea what the mallopt calls do (that is, I
> can see in the documentation that they modify such and such parameter of
> the allocator, but I don't know what that means in practice: faster,
> slower, less RAM, more RAM, etc).

AFAIU:

  . mallopt (M_MMAP_MAX, 0) forces malloc not to use mmap when we
    think it's sub-optimal
  . mallopt (M_TRIM_THRESHOLD, 128 * 1024) makes us use sbrk less often
  . mallopt (M_MMAP_THRESHOLD, 64 * 1024) favors mmap allocations for
    smaller objects/buffers than the default, thus making it easier
    for Emacs to release unused memory to the system
  . mallopt (M_MMAP_MAX, MMAP_MAX_AREAS) tells the library that there
    should be no limit on allocations via mmap, since Emacs is a
    single-threaded application

> So I hope some more clueful people will chime in.

Seconded.