Re: Emacs bzr memory footprint

[Nix <nix@esperi.org.uk>]

On 21 Oct 2011, Dmitry Antipov outgrape:

> On 10/21/2011 07:22 PM, Nix wrote:
>
>> Really? I double-checked the glibc-2.12 malloc source
>
> Hmm... I didn't check the sources and didn't any tests, but info manual from 2.14 says:
>
> `M_MMAP_THRESHOLD'
>          All chunks larger than this value are allocated outside the
>          normal heap, using the `mmap' system call.  This way it is
>          guaranteed that the memory for these chunks can be returned
>          to the system on `free'.  Note that requests smaller than
>          this threshold might still be allocated via `mmap'.

They might. If sbrk() fails, mmap() is tried instead before giving up.
However, in this case, resetting the mmap threshold isn't going to help:
it'll try anyway.

> The manual may be outdated, so I'll check this too. If you're right,
> these calls of mallopt (M_MMAP_MAX, 0) becomes redundant with never glibcs
> (but still should present for compatibility with old versions).

IIRC glibc malloc has always worked this way (in fact I think it worked
this way even back when it was Doug Lea's malloc, before Wolfram Gloger
took over maintenance). It's got less aggressive in use of mmap() over
the years, but has never allocated storage below the minimum threshold
except in dire straits, because mmap() is so slow. It certainly worked
this way when I first looked at it back in the 2.2 days.

(Though the calls are indeed harmless unless you want glibc's newer
auto-weighting, which I think we probably don't for Emacs as it would
make our existing fragmentation problems even worse.)

--- current bloat score, holding steady:

STIME     TIME   RSS    VSZ
13:38 00:12:07 374056 561116

-- GC165 end: lisp data 173241 Kb (144386 live, 28854 free), 139720 mem nodes (6549 Kb), heap 303948 Kb used, 78115 Kb free

(This sort of rising in bursts is also characteristic of heap
fragmentation.)