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.
