[RFC] Replacing malloc_get_state functionality.

[RFC] Replacing malloc_get_state functionality.

[Ondřej Bílka]

Hi,

I as glibc contributor want to ask how feasible is replacing 
malloc_get_state functionality in unexec by something else. 
If so we could deprecate it for new binaries and use better malloc.

In libc having to support it increases our maintaince burden and
indirectly harms performance of most applications as this gets in the
way of neccessary optimizations.

There are several ways how to do this, one would be use generic dump
framework, second would be separate malloc into standalone library and
linking with that would ensure it would work forever. Or some other way
that I am unaware of?

Ondra

Re: [RFC] Replacing malloc_get_state functionality.

[Paul Eggert]

Ondřej Bílka wrote:
> I as glibc contributor want to ask how feasible is replacing
> malloc_get_state functionality in unexec by something else.
> If so we could deprecate it for new binaries and use better malloc.

It's feasible.  You can run an Emacs today that doesn't use glibc's 
malloc_get_state.  Configure Emacs like this:

./configure emacs_cv_var_doug_lea_malloc=no

This tells 'configure' to assume that malloc_get_state does not work.

Re: [RFC] Replacing malloc_get_state functionality.

[Ondřej Bílka]

On Thu, Feb 20, 2014 at 11:38:00PM -0800, Paul Eggert wrote:
> Ondřej Bílka wrote:
> >I as glibc contributor want to ask how feasible is replacing
> >malloc_get_state functionality in unexec by something else.
> >If so we could deprecate it for new binaries and use better malloc.
> 
> It's feasible.  You can run an Emacs today that doesn't use glibc's
> malloc_get_state.  Configure Emacs like this:
> 
> ./configure emacs_cv_var_doug_lea_malloc=no
> 
> This tells 'configure' to assume that malloc_get_state does not work.

Thanks,

so we could remove it and you will not be affected much?

Re: [RFC] Replacing malloc_get_state functionality.

[Andreas Schwab]

Paul Eggert <eggert@cs.ucla.edu> writes:

> Ondřej Bílka wrote:
>> I as glibc contributor want to ask how feasible is replacing
>> malloc_get_state functionality in unexec by something else.
>> If so we could deprecate it for new binaries and use better malloc.
>
> It's feasible.  You can run an Emacs today that doesn't use glibc's
> malloc_get_state.  Configure Emacs like this:
>
> ./configure emacs_cv_var_doug_lea_malloc=no
>
> This tells 'configure' to assume that malloc_get_state does not work.

Does it still work, though?

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: [RFC] Replacing malloc_get_state functionality.

[Stefan Monnier]

>> 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)?


        Stefan

Re: [RFC] Replacing malloc_get_state functionality.

[Daniel Colascione]

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?

Re: [RFC] Replacing malloc_get_state functionality.

[Paul Eggert]

'./configure emacs_cv_var_doug_lea_malloc=no' works for me in the sense 
that I can do a 'make bootstrap' on Fedora 20 x86-64, and the resulting 
Emacs works interactively.  In this configuration Emacs supplies its own 
malloc so the performance is not quite as good (text 0.5% larger, data 
7.6% larger, 14% more CPU time on my usual benchmark) but I don't 
observe any bugs.

It's possible that there's a bigger problem here; but if so, wouldn't it 
the same bigger problem exist on non-glibc platforms already?  If so, 
any fix should also work on any future glibc platforms that lack 
malloc_get_state.

More generally, Emacs by itself should not inhibit glibc from making 
significant malloc performance improvements that would benefit a large 
set of programs.  If Emacs is the main reason these improvements aren't 
being made, then we should go ahead and make them, as we should be able 
to tweak Emacs to work well with the resulting system.

Re: [RFC] Replacing malloc_get_state functionality.

[Ondřej Bílka]

On Mon, Feb 24, 2014 at 03:51:47PM -0800, Daniel Colascione wrote:
> 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?

Yes, but there is lower hanging fruit around. Most noticable would be
memory savings from omitting headers, currently we add 16byte overhead
per allocation.