Is "Out of Memory" a recoverable error?

[Walter Bright]

Leandro Lucarella wrote:
> For example, I'm working on a softswitch (unfortunately no in D). Lets say
> we have a really bad moment and all the subscribers want to talk at the
> same time and we don't support that workload. Lets say our memory is
> exhausted and a new call arrive. A new allocation is done somewhere deep
> inside the call logic, so the PRE COLLECT callback is called. No memory
> can be reclaimed, so the GC runs a collection. Still no memory. POST
> COLLECT and CRISIS are called too without success. My softswitch is down,
> I lost all the current calls. This is not good for business. What I really
> wanted to do is to catch the memory error as shallow in the call logic as
> possible and drop only that current call, leaving all the current
> established calls intact.
> 
> So what can I do? Should I manually check each and every allocation in all
> the call logic? I think that's unacceptable.
> 
> I think this scenario apply to each client-server application that needs
> to stay alive even with high workloads, as the expense of dropping some
> connection/client (web servers or web applications for example, as someone
> said in stackoverflow.com).

Ok, I thought about this for a while. When a virtual memory system gets 
close to running out of memory, it slows to a crawl and starts thrashing 
the disk. Other processes on the computer also start to fail by running 
out of memory. The program will continue to function, but it will 
function so poorly it might as well have aborted.

The solution is to calculate (or measure) the average memory consumption 
of each call. Determine the maximum memory the software should 
reasonably consume without thrashing, divide by the memory consumption 
per call, and that gives a max number of simultaneous calls. Drop calls 
that exceed that.

This scheme should work better, and still provides some slack if the 
calls dramatically exceed their average memory consumption.