Andi Gutmans wrote: > At 12:53 PM 6/9/2002 -0700, Aaron Bannert wrote: > >> On Sun, Jun 09, 2002 at 03:09:24AM +0300, Zeev Suraski wrote: >> > Hmm, but doesn't that mean that the largest contiguous block this >> heap will >> > be able to provide is 8KB, then? >> >> 8K is just the minimum chunk size, there is no absolute maximum. >> >> > > * There's a two-layer structure to the heaps: >> > > - apr_pool objects are what the application uses. Each pool >> > > provides a fast alloc interface, no free function, and a >> > > "destructor" that returns all the allocated space when the >> > > pool is destroyed. >> > >> > This is probably not very suitable for PHP. We allocate and free >> *a lot*, >> > not being able to free is going to increase memory consumption >> > significantly. If we use APR heaps, are we bound by this behavior? >> >> The expectation is that pools are cleared at normal intervals, so >> that eventually the memory allocation for an application reaches a >> "steady state". In PHP this could be accomplished by simply using >> the per-request pool that is already available when the internal PHP >> functions are called from httpd. At the end of a request this pool is >> "cleared", and then able to be reused on subsequent requests. > > > I haven't looked at the source for too long but it seems to be much > worse than HeapCreate().If it doesn't have a node for a certain size > it uses malloc(). So in the end it seems as if you might reach a > situation where you do lots of malloc()'s instead of allocating > another few pages and dividing them up yourself without mutexes. > Please correct me if I'm wrong. I haven't had time to study this code > in great depth.
If a pool doesn't have enough space to handle an allocation, it will obtain (from it's allocator's free block list, if possible, or else from malloc) either: 1) an 8KB block, if the requested allocation is < 8KB, or 2) a big gnough block to handle the requested allocation if it's bigger than 8KB. (The apr_allocator code layered benath the pools has multiple free lists for various sizes of small blocks, and it will do mallocs for small blocks if its free list is empty. But the pool API just requests 8KB blocks and carves up the space within them.) Whether this is useful for PHP depends on the allocation pattern of a typical request. If the total size of all the allocations required during an average request is small enough to fit within a couple of 8KB blocks (without freeing any of the allocated chunks until the end of the request), then pools will probably work well. If not, then we'd need a different allocator design--one that allowed allocated blocks to be freed at any point during the processing of a request. There's been some discussion in the past about adding support for "apr_pfree()" to complement apr_palloc(), but that's still just in the concept stage. I'm definitely interested in learning more about the allocation patterns of PHP--if the current APR pool semantics end up not being suitable, that knowledge could help us improve the APR allocator design in the future. Thanks, --Brian -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
