std.experimental.allocator.make should throw on out-of-memory

[Thiez via Digitalmars-d]

On Thursday, 21 April 2016 at 13:42:50 UTC, Era Scarecrow wrote:
> On Thursday, 21 April 2016 at 09:15:05 UTC, Thiez wrote:
>> On Thursday, 21 April 2016 at 04:07:52 UTC, Era Scarecrow 
>> wrote:
>>>  I'd say either you specify the amount of retries, or give 
>>> some amount that would be acceptable for some background 
>>> program to retry for. Say, 30 seconds.
>>
>> Would that actually be more helpful than simply printing an 
>> OOM message and shutting down / crashing? Because if the limit 
>> is 30 seconds *per allocation* then successfully allocating, 
>> say, 20 individual objects might take anywhere between 0 
>> seconds and almost (but not *quite*) 10 minutes. In the latter 
>> case the program is still making progress but for the user it 
>> would appear frozen.
>
>  Good point. Maybe having a global threshold of 30 seconds 
> while it waits and retries every 1/2 second.
>
>  In 30 seconds a lot can change. You can get gigabytes of 
> memory freed from other processes and jobs. In the end it 
> really depends on the application. A backup utility that you 
> run overnight gives you 8+ hours to do the backup that probably 
> takes up to 2 hours to actually do. On the other hand no one 
> (sane anyways) wants to wait if they are actively using the 
> application and would prefer it to die quickly and restart it 
> when there's fewer demands on the system.

But background processes might run for months, so having a global 
threshold of 30 seconds combined with a 0.5 second delay between 
retries may result in too few retries in the long run.

So if the retry thing is really the way you want to go you 
probably need to keep track of how many times you've retried 
recently, and then slowly forget about those retries as more time 
passes (time spent waiting for a retry doesn't count). Of course 
this demands additional bookkeeping, but the overhead should be 
acceptable: the 'allocation succeeds' happy path doesn't need to 
know about any of this stuff.

But at the end of the day I would expect the user to be much 
happier if the software simply informs them of insufficient 
memory. The proposed retry scheme would only really have a 
positive effect when the system the software runs on spends a 
significant amount of time flirting with OOM, while never quite 
reaching it to the point where other applications start crashing. 
I think this scenario is very rare/unlikely, and if it occurs the 
user would benefit much more from shutting down some other 
applications, buying more RAM, or (*shudder*) by allowing 
swapping. By silently retrying you are effectively denying the 
user the information they need to solve the actual problem.

Meanwhile, on some operating systems (e.g. Linux) the system will 
happily hand out more memory than it physically possesses, 
because as long as you don't write to that memory it doesn't need 
its own page, so allocations will never return null (for some 
values of 'never', they can still return null if you run out of 
virtual memory, but on a 64-bit system that will realistically 
only happen if you specifically write your program to trigger 
this scenario). Writing to memory can summon the OOM-killer, 
which will kill processes to satisfy its desire to feast on the 
bodies of the fallen. On such a systems attempting to defend 
against allocation returning null seems rather pointless.