apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ron Park <r...@cnet.com>
Subject Re: [PATCH] Free memory over a certain threshold back to the system
Date Thu, 07 Feb 2002 16:50:12 GMT
I know I would like to see the allocator more exposed.  For instance, for
some pools, I'd like to be able to initialize it with much less than the
8K default.  Sure I'm running on an 8G machine, but why waste space I know
I won't need. :)

Thanks,
Ron

Sander Striker wrote:
> 
> > From: Brian Pane [mailto:brian.pane@cnet.com]
> > Sent: 07 February 2002 04:21
> 
> >> It is the memory on the freelists that grows without bounds.  The patch
> >> free()s memory that is added to a freelist when the freelist already
> >> holds a certain amount of free memory.  This is very usefull when you
> >> have peak memory usage as some people pointed out.
> >>
> >> The pools model is something you are stuck with it if you want to use APR.
> >> And it is not always pools abuse which gives you big chunks of mem on
> >> the freelist.  Although I must admit that I would recommend some
> >> serious review of the code which shows this behaviour.
> >>
> >> Anyhow, I'd like to add a configure option which you can feed the
> >> amount of memory you want as a maximum on a freelist, defaulting
> >> to infinite.
> >>
> >> Thoughts?
> >>
> >> Sander
> >
> > I like the idea of a configurable maximum.  It probably should
> > be run-time configurable rather than build-time configurable,
> > though.  It would be even better if the max free list size could
> > be specified on a per-allocator basis, so that the application
> > developer could tailor the properties of each free list to the
> > needs of the app.
> >
> > --Brian
> 
> That certainly can be coded up.  We only need to think about an API.
> Currently I am playing with the idea to factor the allocator out,
> and expose it.  This would give us the opurtunity to add a set_max_free
> function in there.  Placing it in the apr_pools namespace is something
> I'd rather not do.
> 
> Sander

-- 
Ronald K. Park, Jr.
ronp@cnet.com           CNET Networks / CNET.com / ZDNet / mySimon
 908.541.3738           The source for computers and technology.

Mime
View raw message