Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!wuarchive!sdd.hp.com!elroy.jpl.nasa.gov!decwrl!pa.dec.com!src.dec.com!Mike_Spreitzer.PARC@xerox.com
From: Mike_Spreitzer.PARC@xerox.com
Newsgroups: comp.lang.modula3
Subject: Re: NEW out of memory
Message-ID: <91Feb14.074224pst.16323@alpha.xerox.com>
Date: 14 Feb 91 15:40:19 GMT
Lines: 25
In-Reply-To: "<1991Feb14.131207.4189@hollie.rdg.dec.com>"
To: M3
X-Ns-Transport-Id: 0000AA008EE7FE912B35
Cc: Mike_Spreitzer.PARC@xerox.com

Indeed, it seems that the way for a careful program to avoid allocating itself
into a corner involves a two-level allocation scheme.  At the lower level,
where NEW works, there must be multiple heaps; let's call these ZONEs.  Each
invocation of NEW is given the ZONE from which the object is to be allocated.
At the upper level, ZONEs are created with specific sizes, and associated with
specific user requests.  The necessary size of a ZONE is computed by the
program from the user request.  If the ZONE creation fails, the user is told
his request can't be satisfied.  If the ZONE creation succeeds, the request is
granted and worked on.  The idea is that the programmer has estimated,
calculated, or measured a relation between user requests and the amount of
memory needed to satisfy those requests.  This brings the failure point forward
to the time at which refusal of service is reasonable.  In the dialysis
example, the user request would be something like "maintain a new patient of
such-and-such a weight, blood type, etc".  If there isn't enough memory to do
that, the user finds out about it up front, and has a chance to take plausible
corrective action (try a different ward, kick off some other users, whatever).

I know estimating and measuring are not really good enough in critical
applications.  And calculating can be very tedious or outright impossible,
depending on the structure of the application.  But what choice is there,
really?  I take comfort in the philosophy that abstractions are for programmers
to make and compilers (and other tools) to break, and thus the hope that I
won't have to do such calculations by hand.

Mike