Re: [APC-DEV] APC b0rkage upcoming

[email protected] (Brian Shire) Tue, 8 Jan 2008 12:59:24 -0800
Newsgroups php.apc.dev
Message-ID <[email protected]>
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
>