apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sander Striker" <stri...@apache.org>
Subject RE: [PATCH] Free memory over a certain threshold back to the system
Date Thu, 07 Feb 2002 02:56:39 GMT
> From: Ryan Bloom [mailto:rbb@covalent.net]
> Sent: 06 February 2002 18:02
> > -----Original Message-----
> > From: Justin Erenkrantz [mailto:jerenkrantz@ebuilt.com]
> > Sent: Wednesday, February 06, 2002 8:59 AM
> > To: Sander Striker
> > Cc: dev@apr.apache.org
> > Subject: Re: [PATCH] Free memory over a certain threshold back to the
> > system
> > 
> > On Wed, Feb 06, 2002 at 01:24:36PM +0100, Sander Striker wrote:
> > > Hi,
> > >
> > > The 'high free' patch.  I'm not sure we want this.
> > > It may hide pools abuse problems.
> > 
> > Yeah, I agree we don't really want this.  If we run out of memory
> > with the normal pools, it means that the lifetimes are most likely
> > incorrect.
> > 
> > But, perhaps this could be a #define with a debug option?  -- justin
> We definitely don't want this IMHO.  If the pools are filling up, then
> either pools are the incorrect model for your app, or they aren't being
> cleared often enough.  I would much rather not have this as an option at
> all, because that just encourages people to use it.  :-)
> Ryan

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.



View raw message