Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!olivea!decwrl!pa.dec.com!hollie.rdg.dec.com!jch From: jch@dyfed.rdg.dec.com (John Haxby) Newsgroups: comp.lang.modula3 Subject: Re: NEW out of memory Message-ID: <1991Feb14.131207.4189@hollie.rdg.dec.com> Date: 14 Feb 91 13:12:07 GMT References: <9102131002.AA01768@decpa.pa.dec.com> Sender: news@hollie.rdg.dec.com (Mr News) Reply-To: jch@dyfed.rdg.dec.com (John Haxby) Organization: Digital Equipment Corporation Lines: 45 Checking for lack of memory doesn't really help in two out of three cases that I can think of. The good case is when the program has simply run up against the heap limit (eg 32Mb on ULTRIX 4.1) in which case, the program should abort gracefully--there are problems with this that I'll get to in a minute. The bad cases are two variants of the system running out of resources for (virtual) memory. In simple VM schema (like ULTRIX's) where space is pre-allocated or pre-reseved, running out is fairly serious as programs start failing all over the place; to be honest, in this scenario, system managers are likely to treat large processes (eg editors written in modula 3 consuming lots of memory) as fair game and any attempt by the program to struggle on is going to be fruitless. Admitedly, the user could choose to terminate gracefully, apart from the problem that I'll get to in a minute. The second variant of running out of VM resources is found in systems that do lazy allocation of resources (eg Mach) where the ru nning program is happily allocating memory, but when it tries to use that memory it gets peremptorily killed. The problem that I have been getting on to in a minute is what happens when the running process gets an exception to say that no more memory is available. What can it do? The answer is anything that doesn't involve allocating memory. In practice, I suspect, this wouldn't even including the editor writing files out to disk and freeing up associated buffers (at least not without some very careful programming). In any language where storage allocation is cheap and easy, there is a lot of it (although I don't know exactly how this affects Modula 3), and when you run out you may as well give up. The question arises: how much care *should* you take to deal with lack of VM resource? Well, how often do you run out? The attitude that Mach takes is "almost never, so you can allow deliberate over-allocation". Experience bears this out: I have been using an editor (admitedly not written in Modula anything) for several years that simply dies on lack of memory, and it has never died on me unless the system has gone down as well. So why go to all that trouble? It is *possible* to run out of VM, but it d oesn't happen all that often, and when it does, the consequences are so serious for everything that the odd application keeling over makes little difference. Reading that last paragraph again, the begging question is "under what circumstances *must* you deal with lack of memory?" The answer seems to be "when the application is critical". Under these circumstances, the application must take steps to ensure that it doesn't run short of memory when it needs it. The obvious way to do this is to ask the operating system how much memory can be allocated to this process before before it runs out of space. This, obviously, is highly O/S dependent, and some VM systems ( eg Mach's) may not even know how much space can be allocated before resources become a problem. The way *not* to do this is to introduce a "TRYNEW" request--this is too late. You need to know if VM shortfall is going to be a problem soon, not right now. If you need to allocate space to deal with the kidney dialysis (or however you spell it) in order to keep the patient alive, then "I'm sorry, I can't allocate enough memory is going to help" You need to know well in advance that in order to allocate enoug h memory for what you might need to do that you need to kill that emacs or that motif application. This problem gets to the stage where we no longer deal with language constructs, but operating system services and application requirements to *avoid* the lack of memory exceptions, not to do something sensible when you get them, because nothing sensible can be done at that late stage. [Sorry if all this is garbled, it's written in a bit of a rush and I haven't had time to review it properly (to all those who say that I shouldn't have written it in the first place, I am inclined to agree] -- John Haxby, Definitively Wrong. Digital Reading, England <...!ukc!wessex!jch>