At 9:00 AM +0200 5/17/02, Peter Gibbs wrote:
>A side effect of the split pools is targeted compaction i.e. the buffer pool
>gets compacted only when it is full, and the string pool likewise - this
>does provide a performance benefit in situations where one pool grows
>regularly and the other does not. If we were to eliminate the separation of
>pools based on type, perhaps we need to consider some other means of having
>multiple pools, purely for performance reasons. This could, for example, be
>based on the buffer header size, so each resource pool would have its own
>memory pool.
This is one thing I definitely considered, and one I think is a good
idea. We're going to have a mix of allocation longevity
here--constants will live for ages, as will code segments we create
on fly, while strings and buffers may live less long. Allowing for
multiple pools means we can delay collecting things we know don't
need collection as often.
Consider it an alternative to generational collection, which will be
somewhat problematic for us, I think. (Well, maybe...)
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
