D Language 2.0

[Walter Bright]

Michel Fortin wrote:
> But that's probably just a bug somewhere.

We decided that gc allocations are allowable inside a "nothrow" 
function. The idea is that there are two classifications of exceptions - 
recoverable and non-recoverable. "nothrow" only refers to recoverable 
ones. Out of memory is non-recoverable. (Assert errors are also 
non-recoverable.)

Yes, you can argue that o-o-m should be recoverable. But in practice, it 
rarely is. Furthermore, by classifying o-o-m as recoverable, it makes 
"nothrow" functions next to useless.

It seems a very reasonable tradeoff to make it unrecoverable.

So no, it's not a bug, it's a deliberate design choice.

===================================

It's very, very difficult to design a program that can recover from out 
of memory if it allocates memory in bits and pieces all over the place. 
Any one of those can fail, and then the recovery code will fail as well 
as it cannot allocate memory either.

Often programs that purportedly can recover from oom actually cannot, 
because they were never tested and the recovery code doesn't work. It's 
kinda hard to devise a test suite that will try failing at every single 
point memory is allocated. Hardly anyone bothers.

You can design a system that has "free these blobs of memory I'm keeping 
in reserve if I run out and hopefully that will be enough", but that 
strategy needs to be part of the gc itself, not user recovery code.

Generally, what programs need to do if they run out of memory is try to 
abort as gracefully as possible, and hopefully restart the program. You 
don't need exception unwinding to make that happen.