On Mon, 27 May 2002, Jerome Vouillon wrote: > On Sun, May 26, 2002 at 08:20:23AM -0700, Sean O'Rourke wrote: > > I'm sure it's been discussed before somewhere, but why can't we guarantee > > that we only do GC runs between ops? Each op would just have to guarantee > > that all of its persistent data is reachable before it returns. It seems > > like this would avoid the need for a neonate flag entirely. > > If you know how much memory the op is going to need, then you can run > the GC just before executing the op to make sure that at least this > amount of memory is available (and non fragmented). But this seems to > be a pretty strong requirement.
But there are two kinds of "available" here: available without asking the operating system for more; and available period. If we're in the first situation, it seems reasonable to just ask the OS for a new block and keep going, noting that collecting soon would be a Good Thing. Our memory requirements have probably increased, so we'd be asking for more soon anyways, and if they haven't, we'll reclaim a lot of memory on the next collection, and only be "wasting" 8 or 16k. We can even try to give some back, though the OS probably won't take it. If we're in the second situation, then either (1) we've gone far too long without collectiong, or (2) we're in serious trouble anyways. And even in this situation, we can wriggle out of it most of the time by keeping some amount of "emergency" memory stashed away. This may not work on embedded systems, but not having developed for one, I hate to just throw away the idea based on my ill-founded suspicions. > Otherwise, you should be able to run the GC whenever you allocate some > memory. Since our memory-allocating routines return NULL quite a ways back up the call chain (all the way through e.g. string_grow()), here's another way to do this -- if allocation returns NULL all the way to an op function, it can make the things it wants to keep reachable from somewhere, do a collection, and retry. By the way, neither of string_grow()'s callers checks its return value now, which indicates to me that this may be error-prone. /s
