[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSAutoreleasePool does not free all memory

From: Richard Frith-Macdonald
Subject: Re: NSAutoreleasePool does not free all memory
Date: Mon, 30 Apr 2001 12:56:48 +0100

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
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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]