Re: Emacs bzr memory footprint

[Nix]

On 21 Oct 2011, Óscar Fuentes told this:
> The memory for the text of a buffer, is a single chunk? Or, more
> generally, are large chunks of memory allocated for big buffers? If the
> answer is yes, memory fragmentation may be problematic for those who
> work with large buffers, unless the allocating algorithm avoids that.

Emacs goes to some lengths to avoid allocating memory on the brk()ed
heap for buffers of significant size. The rules are somewhat arcane.

On a limited number of platforms (currently Cygwin, FreeBSD and IRIX
6.5), mmap() is used to map buffer text directly.

On platforms using the copy of Doug Lea's malloc() in src/gmalloc.c (or
using Doug Lea's malloc without being a GNU system, if any such systems
exist), buffers are allocated using the frankly terrifying
block-relocating memory allocator in ralloc.c, which uses sbrk()
directly and arranges for blocks allocated that way to dodge out of the
way of malloc() using the morecore_hook. (I'd be scared to trust my data
to this one.)

On GNU platforms which appear to be using Doug Lea's malloc(), we turn
this off and just use malloc() directly.

Emacs relies on all of these allocating the buffer storage in a single
(virtually) contiguous chunk (modulo the gap): the gap-motion code in
insdel.c, and much else, depends on being able to use simple pointer
arithmetic to move around the buffer.

-- 
NULL && (void)