[Top][All Lists]

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

Re: When should ralloc.c be used?

From: Eli Zaretskii
Subject: Re: When should ralloc.c be used?
Date: Mon, 24 Oct 2016 22:38:22 +0300

> From: Stefan Monnier <address@hidden>
> Cc: address@hidden, address@hidden
> Date: Mon, 24 Oct 2016 14:45:59 -0400
> >> > Using mmap has disadvantages: when you need to enlarge buffer text,
> >> > and that fails (because there are no more free pages/addresses after
> >> > the already allocated region), we need to copy buffer text to the new
> >> > allocation.
> >> All allocators suffer from this problem.  I haven't seen any evidence
> >> that the mmap-based allocation code is significantly more prone to it.
> > I have seen that.
> Could you give some details (mostly about the scale of the problem)?

Visiting a large compressed file (e.g., an Emacs release tarball
compressed with gzip) takes with mmap several times as long as in a
build without mmap.

> > Not entirely true: ralloc calls the system sbrk with a negative
> > argument when it feels like it.
> That's why I said "basically".  Yes, in theory it can sometimes
> return memory.  In practice, this is rare.  In contrast, with mmap,
> returning memory to the OS is the rule rather than the exception.

How so?  Releasing memory in both cases requires basically the same
situation: a large enough block of contiguous memory not in use.  It
seems ralloc is actually at an advantage, because relocating blocks
helps collect together a larger free block.

reply via email to

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