Re: When should ralloc.c be used?

[Daniel Colascione]

address@hidden (Jérémie Courrèges-Anglas) writes:

> Daniel Colascione <address@hidden> writes:
>
>> On 10/24/2016 08:40 AM, Eli Zaretskii wrote:
>>>> From: Stefan Monnier <address@hidden>
>>>> Cc: address@hidden,  address@hidden
>>>> Date: Mon, 24 Oct 2016 10:37:19 -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.
>>
>> 64-bit address spaces are *huge*. What about just making every buffer
>> allocation 2GB long or so, marked PROT_NONE? You don't actually have to
>> commit all that memory --- all you've done is set aside that address
>> space.
>
> IIUC you suggest relying on memory overcommit.  That doesn't sound
> portable at all.  Not all OSes do overcommit and the ones who do
> generally provide a way to disable it.

You understand incorrectly. "Overcommit" is the practice of allowing an
operating system to lie about how much memory it's guaranteed to give
applications in the future.  We're not talking about guaranteed
memory. We're talking about setting aside address space only, not asking
the OS to make guarantees about future memory availability.  All major
operating systems, even ones like Windows that don't do overcommit,
provide ways to reserve address space without asking the OS to guarantee
availability of memory.

That said, my idea probably isn't the best --- but it doesn't rely
on overcommit.