[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Should use of mallopt depend on DOUG_LEA_MALLOC?
From: |
Paul Eggert |
Subject: |
Re: Should use of mallopt depend on DOUG_LEA_MALLOC? |
Date: |
Fri, 13 Dec 2019 13:55:36 -0800 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 |
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.
But the ones conditionalized on `mmap_lisp_allowed_p` are used not as
optimizations but to prevent use of mmap within the malloc
implementation in the two known cases where it can break our
(unportable) assumptions:
Yes, we need to keep those only for the vanishingly small cases where we
use unexec and a Doug Lea-like malloc.
I looked through Emacs's uses of mallopt. There's a lot of cargo-cult
cruft there that should go. Plus, I expect there's a real bug with newer
glibc (so mallopt isn't called) but unexec is still used (because the
builder asked for it - a mistake in my view) and where Emacs doesn't
disable mmap properly.
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).
0001-Simplify-use-of-mallopt.patch
Description: Text Data