Re: NSAutoreleasePool does not free all memory

[Richard Frith-Macdonald]

On Monday, April 30, 2001, at 10:49 AM, David Wetzel wrote:

> Richard Frith-Macdonald wrote
>
> > Autorelease pool memory is *not* freed (unless the thread they belong 
> > to
> > is terminated) ... the autorelease pool objects are
> > cached for later re-use ... so this memory will remain in use, and will
> > stop the whole block of memory being returned to the operqating system.
> >
> > This is of course harmless, since the memory will be re-used the next
> > time any
> > object is allocated, (so memory usage will not grow indefinately) and 
> > if
> > nothing
> > ever is allocated again, it will be paged out to disk.
>
> I don't like this strategy. Paging is always slow. It is the operating 
> system's task to manage free memory.
> Imagine you have multiple GSWeb instances. Each eats 100 MB but would 
> only use 20 if the memory would be freed.
> You are using swap disk space where you don't have to.
>
> Modern operating system (and I guess Linux is one too in this aspect) 
> should be far better optimized than GNUstep.
>
> Maybe I miss something here but...

I think you missed the main thrust of my email ... or I expressed myself 
very poorly.

We aren't talking about taking memory management away from the operating 
system - the system
is managing memory as normal.
What we are talking about there is normal behavior for malloc/free ... 
if any bit of memory
is in use the malloc implementation may not give any back to the 
operating system (and the
operating system is designed not to expect it to be given back until the 
process exits).
This is pretty harmless and *doesn't* cause the program to use more 
memory than it would
otherwise.

Your problem is that you are using a relatively meaningless 
statistic ... the reported memory
size of an application is actually its *peak* size, not its current 
size.  True, it's relevant
to the swap space on your system, but not much else.

In fact, your little test program demonstrates an unrealistic and 
misleading situation when
not using autorelease pools, and a more normal situation when using them.

I could change the autorelease pool implementation so that pools are not 
cached and the memory
they use is freed as soon as the pool is released, but the only effect 
that would have on real
programs is to slow them down slightly as each creation/destruction of a 
pool would
require a malloc/free overhead.