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

[Noam Postavsky]

[Moving to emacs-devel, since this doesn't seem to be about the bug as such.]

Eli Zaretskii <address@hidden> writes:

>> From: Noam Postavsky <address@hidden>
>> Cc: address@hidden,  address@hidden,  address@hidden
>> Date: Sat, 07 Dec 2019 14:25:06 -0500
>> 
>> > So does this mean modern glibc has no knobs to tailor its behavior to
>> > various needs, like set the threshold for using mmap, etc.?  IOW, no
>> > more support for the likes of mallopt?
>> 
>> 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 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).  So I hope some more clueful people will
chime in.