Is "Out of Memory" a recoverable error?

[Leandro Lucarella]

Walter Bright, el  5 de diciembre a las 15:04 me escribiste:
> 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.

This is not still the only possible case. See this:

luca at homero:/tmp$ cat mem.d

import core.stdc.stdio: printf;
import core.exception: OutOfMemoryError;

void main()
{
	try {
		auto x = new char[1_000_000];
	} catch (OutOfMemoryError e) {
		printf("woops! no more memory\n");
	}
}

luca at homero:/tmp$ ulimit -v 3000
luca at homero:/tmp$ dmd mem.d
luca at homero:/tmp$ ./mem
woops! no more memory

I swear my system didn't trash! =)

This is not some stupid thing just to prove you wrong. When I want my
process to live for as long as possible, even in extreme situations like
lack of memory, it's a very good option to do this. Because of the reasons
you gave about trashing. Its more desirable that my softswitch start
dropping calls a little earlier than necessary but can maintain the
current ones smoothly, than let the system trash and hope for the best.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
DETIENEN A PADRE, MADRE, TIOS Y ABUELOS: TODOS DEPRAVADOS
	-- Crónica TV