apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gonzalo Arana" <gonzalo.ar...@gmail.com>
Subject Re: svn commit: r647394 - in /apr/apr/trunk: CHANGES include/apr_pools.h memory/unix/apr_pools.c
Date Wed, 16 Apr 2008 17:45:58 GMT
Hi,

On Wed, Apr 16, 2008 at 11:00 AM, Joe Orton <jorton@redhat.com> 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

Mime
View raw message