Re: When should ralloc.c be used?

[Jérémie Courrèges-Anglas]

Daniel Colascione <address@hidden> writes:

> 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.

Can you point at some documentation regarding those techniques?  I fail
to find one that would work on my "non-major", mostly POSIX OS.

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

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE