Dynamic system memory use
Marcel Weiher
marcel at metaobject.com
Sat Feb 2 00:21:16 UTC 2002
On Saturday, February 2, 2002, at 01:07 , Andreas Raab wrote:
>
> Not quite. The keyword of this discussion is "lazy" not virtual. I don't
> exactly care where the memory is (that's exactly what the manager is
> for). But I _do_ care that if I call malloc() and get a non-null pointer
> back then I should in fact be able to use that memory block. According
> to the explanations I've heard here that is _not_ the case. In other
> words the "lazy" malloc()ator may give me a pointer from malloc() but at
> the point where I actually start writing to that memory it may say
> "Oops. Sorry. I promised you that memory but I lied. I don't actually
> have any. You loose. Core dumped."
Sort of like a DNU... "Oops, you gave me an object, but it doesn't
actually understand the message. I want a guarantee that the message
will be understood." The answer to that is very similar to the VM
answer: (a) this works better in most real-world scenarios, (b) the
failures you are afraid of are quite rare and (c) if you are really
*that* concerned, there are ways of avoiding the problem.
99% of Unix programs will core-dump just as hard if malloc() returns
NULL, so what this does is (a) fail later and (b) allow some programs to
run that would otherwise not run and (c) allow things to be simplified
significantly. Of course, you can wrap every malloc() with a check for
a NULL return, but the plain fact is that a NULL-return from malloc() on
a Unix system usually means you are hosed anyway, so there isn't really
any point in handling it. Just core-dump and be done with it.
Marcel
More information about the Squeak-dev
mailing list
|