Re: [APC-DEV] APC b0rkage upcoming

Thanks for the overview, I was just looking at the code wondering exactly how it was going to be pieced together. I think having the pool allocation may help me experiment with other projects I've had on my mind as well. This sounds great, thanks! -shire On Jan 8, 2008, at 10:38 AM, Gopal V wrote:

Rasmus Lerdorf wrote:

I know we have talked about it privately, but it might be a good idea to give folks on this list a summary of the goals of the pooling mechanism.

Yup, the pool idea has been in my head for quite a while now. It's there to avoid a lock call for every allocation in the system. Initially, it was supposed to be per-process, but it has been reworked to be per-cache entry. Every entry holds a pool and allocates all memory required from the pool, which pulls in 4/8k blocks. This should speed up the allocation operation, but that's not the key problem I'm trying to fix. More importantly, most segvs in APC seem to happen during cache full conditions when the cache expunge is being performed. Having a pool essentially reduces all free calls into just deallocating the pool blocks (i.e 1+4 sma_free calls for 16k of memory). It'll also reduce the cruft of the cleanup code whenever there's an allocation failure and indirectly ensure that there are no memory leaks. Hope all that made sense. Cheers, Gopal --If I learn from my mistakes, pretty soon I'll know everything --APC Development Mailing List (http://pecl.php.net/APC) To unsubscribe, visit: http://www.php.net/unsub.php