On Mon, May 27, 2002 at 08:41:59AM -0700, Sean O'Rourke wrote: > 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.
I don't think (1) is true. For performance reason, we should let quite a lot of garbage accumulate before triggering a collection (something like 40% of space overhead). So, for instance, if the heap is full and we need to allocate a huge string (10 Mbytes), it is quite likely that performing a collection will free enough memory. And I'm not sure we are ready to always keep 10 Mbytes of "emergency" free memory to be able to handle this case without collection. [...] > By the way, neither of string_grow()'s callers > checks its return value now, which indicates to me that this may be > error-prone. Also, it seems that the return value of alloc_new_block is never checked, even when really huge blocks are allocated, as in compact_buffer_pool... -- Jerome
