Re: When should ralloc.c be used?

[Stefan Monnier]

>> > 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)?

> The native glibc malloc, the on GNU/Linux systems were using until we
> got screwed by the recent glibc, didn't have this problem, while
> mmap-based allocator did.  Don't ask me how glibc does it, I don't
> know; but the fact is there.

It likely mmaps a bit more than requested, like you do in w32heap.c.

>> Another advantage of using mmap is that it can return the memory to the
>> OS once you kill your large buffer, whereas with gmalloc+ralloc this
>> basically never happens, AFAIK.
> 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.


        Stefan