Hi, On Wed, Apr 16, 2008 at 11:00 AM, Joe Orton <[EMAIL PROTECTED]> wrote: > On Tue, Apr 15, 2008 at 06:48:23AM +0200, Mladen Turk wrote: > > Joe Orton wrote: > > > On Sat, Apr 12, 2008 at 08:42:59AM -0000, Mladen Turk wrote: > > >> Author: mturk > > >> Date: Sat Apr 12 01:42:51 2008 > > >> New Revision: 647394 > > >> > > >> URL: http://svn.apache.org/viewvc?rev=647394&view=rev > > >> Log: > > >> Introduce apr_pool_sys_allocator_set > > > > > > Why can't you just use a custom allocator for whatever the problem > > > is here? That's what the allocator abstraction is *for*, right? > > > Adding yet another abstraction above the allocator seems really > > > wrong; especially since it introduces a bunch of global state and > > > *everybody* suffers the overhead of the additional function calls > > > and conditionals. > > > > How can I use custom allocator from outside apr? > > > > The allocator is private, so cannot be customized from application. > > Good point. > > > > It relies on malloc/free, and the point of patch is to abstract those > > calls. Patch itself only sets the function pointer, and since its > > warper is inline function the proper compiler should make no > > overhead except one JNZ instruction. > > > > The point is that apr internally uses system allocator and > > we presume this should be malloc/free. Any other mechanism > > is ruled out by that presumption. malloc/free might not be the > > most effective way to allocate the memory from the system in > > all use cases. It also doesn't allow things like profiling > > and all other sort of things the application might have. > > Can you explain some of those other things might be? There are multiple > ways you can hook into a profiling toolkit without requiring source code > changes: > > 1) compile-time hacks to #define malloc > 2) at link-time link against some library which provides malloc etc > before libc > 3) at load-time LD_PRELOAD a library which overrides libc malloc etc
There is one possible "other thing": you may want to use an mmap'ed based allocator for the request pool & it's children, and a malloc/free based for other, long term pools. I may be wrong about this, but I believe a mmap/munmap based allocator would allow to reduce the simultaneous memory usage, since after a request is processed, the memory would be actually unmaped. Calling free(3) does not always reduce the process memory usage (on Linux at least). Regards, -- Gonzalo A. Arana
