Re: When should ralloc.c be used?

[Ken Raeburn]

On Oct 24, 2016, at 09:05, Eli Zaretskii <address@hidden> wrote:

> 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.  This happens quite a lot when we visit a compressed
> buffer.  (The MS-Windows emulation of mmap in w32heap.c reserves twice
> the number of pages as originally requested, for that very reason.)

In the general case, yes.  But modern Linux kernels have an “mremap” system 
call which can “move” a range of pages to a portion of the address space that 
can accommodate a larger size, by tweaking page tables rather than copying all 
the bits around.  I’m pretty sure modern glibc realloc uses it.  I had a 
project a while back where code ported to Solaris ran far slower than the 
GNU/Linux version because lots of realloc calls were done on a large array; 
Solaris copied, GNU/Linux remapped.

  void *mremap(void *old_address, size_t old_size,
               size_t new_size, int flags, ... /* void *new_address */);

Of course you can’t shift bytes within a page this way, or add new space 
anywhere but after the last page of the old region.  (No hint in the man page 
whether you can use an explicit new address range overlapping the old range to 
shift a chunk of memory a la memmove, or if the results would be undefined a la 
memcpy.)

I don’t know if any other systems support it.  The performance savings for one 
of our favorite systems might be worth the special-casing.  Though, if glibc 
realloc does the right thing, maybe using malloc/realloc for buffer storage 
would suffice.

Ken