[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs bzr memory footprint

From: Nix
Subject: Re: Emacs bzr memory footprint
Date: Fri, 21 Oct 2011 13:47:35 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.90 (gnu/linux)

On 21 Oct 2011, Eli Zaretskii said:

>> Date: Fri, 21 Oct 2011 13:05:42 +0100
>> What, even if what's happening is massive allocation of conses followed
>> by allocation of longer-lived stuff followed by freeing of those conses?
> I'm really not an expert on this, but I think the answer is YES.  At
> least the GNU/Linux build does not use the gmalloc.c and ralloc.c
> modules, AFAIK because the native malloc on GNU/Linux includes the
> same or superior functionality.

Unfortunately it won't release memory back to the OS in the situation I
described. mmap() is expensive, so only large allocations (by
default >128Kb or >512Kb depending on glibc version and arch) get
mmap()ed. If you want to e.g. release all storage allocated for a buffer
*and its local variables* when that buffer is freed, you need a pool
allocator which can be told to allocate those local variables in a
buffer-specific mmap()ed pool... and glibc malloc has nothing like it.
(I'm thinking here of something like APR's pool allocators, though
obviously not actually those allocators. Something with a similar design

But this is all speculation. I'm running a debugging patch now courtesy
of Dimitry Antipov: we'll see what it turns up in the next few days (or
even possibly hours).

NULL && (void)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]