apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <brian.p...@cnet.com>
Subject Re: [PATCH] Free memory over a certain threshold back to the system
Date Thu, 07 Feb 2002 03:21:07 GMT
Sander Striker wrote:

>>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.
>
>Thoughts?
>

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



Mime
View raw message