Re: [RFC] Replacing malloc_get_state functionality.

[Daniel Colascione <dancol@dancol.org>]

On 02/24/2014 12:01 PM, Stefan Monnier wrote:
>>> This tells 'configure' to assume that malloc_get_state does not work.
>> Does it still work, though?
>
> And doesn't this have some impacts in terms of Emacs's memory use
> (e.g. retaining more memory instead of returning it via munmap)?

Based on comments in the code, I'm not sure Emacs can operate correctly 
using the system dlmalloc without malloc_set_state:

/* malloc can be invoked even before main (e.g. by the dynamic
    linker), so the dumped malloc state must be restored as early as
    possible using this special hook.  */

When DOUG_LEA_MALLOC is unset, we skip some other heap manipulations 
(like restrictions on mmap allocation of lisp objects) that seems 
essential for correctness.

After the feature freeze, I'd like to look into moving Emacs away from 
sbrk-based allocators in general. It's tremendously wasteful of commit 
charge to keep a large data segment around. (Yes, GNU/Linux systems 
typically overcommit memory, which lessens the impact of the waste. Two 
wrong don't make a right.)

jemalloc works very well for other long-running programs (like Firefox), 
and although good support for concurrent allocation is one of jemalloc's 
main selling points, its fragmentation avoidance features are actually 
much more attractive to me right now.

This work will require breaking support on all platforms for dumping a 
dumped Emacs, but I'm not aware of any platform on which this feature 
works anyway.

Ondřej, are you planning on adding fragmentation resistance to the glibc 
malloc?