On Wed, May 15, 2002 at 09:53:48PM +0200, Peter Gibbs wrote: > [Steve - it seems to me that the 'normal' buffer pool should just be > replaced by the size 0 pool in your new system? I would think twice about > incorporating strings, as that might complicate COW, if it ever happens.]
Yes. In my patch, I commented that I was taking the minimally invasive route, but that the Right way of doing it would be to take over the regular pools, probably leaving behind a cached pointer in the Arenas structure. I was thinking that at the very least, this would clean up the duplicated code for the free_pool_buffers. But your patch is a *much* better way of doing that part. Mostly, I didn't want to make any major changes without the buy-in of the head memory management guys (which primarily means you at the moment.) I've finally managed to get a grip on the different data structures used by the memory subsystem, but it's a tenuous grip at best. I haven't thought this through, but could buffer and string compaction code be merged if you added some sort of flag and function pointer for special handling during compaction? BUFFER_hindu_FLAG: "I may or may not be a cow right now, but I could become one in the future." (Ok, that's obscure. Think reincarnation.) But the size of allocated objects isn't enough to distinguish between different pools anyway. Making different pools for different purposes makes a lot of sense (eg your distinction between constant and non-constant strings). Especially if you believe, as I do, that we'll eventually want to implement some kind of generational scheme so we're not constantly re-scanning long-lived objects.
