Re: Problem with NSAutoreleasePool in GNUstep

[Richard Frith-Macdonald]

On Monday, December 3, 2001, at 03:01 PM, ramana rao wrote:

> Richard,
>
> thanks for the response.
>
> We tried with +freecache, still the memory used by the program is not 
> going
> down.
>
> I still could not get why memory usage is not coming down after [pool
> release]. In OpenStep the memory usage does come down?
>
> This problem is not with particular machine, it is coming on all 
> machines

Can't remember which way the heap grows, but assuming it grows up ...

If you allocate a lot of memory, the heap grows taller.  If you then
free all that memory, the operating system reclaims it, but if anything
at all keeps hold of something near the top of the heap, the operating
system will not reclaim any of it below that bit that is still retained.

The [NSAutoreleasePool +freeCache] method will release any cached 
autorelease
pool objects/memory ... ensuring that the autorelease pool itsself is not
responsible for hanging on to any memory at the top of the heap, but that
does not prevent something else hanging on to memory from near the 
top ...
that something could be in your code, in the GNUstep base code, or even 
in
libc (or other libraries), so in general you can't control it, and it's
an effect of the way the operating system manages memory (this is the way
it works on GNU/Linux, the BSD/Mach operating system may have reclaimed
memory on a page by page basis, which would explain it's not exhibiting
this behavior).

As a rule this effect is harmless ... if most of the memory is not in use
(just a little at the top of the heap), then it will be swapped out, and
no physical memory will be used by it, and the swap usage will not 
continue
to grow because the unused part of the heap will be re-used whenever the
application needs it.

The only time this can really be a problem is with programs which have a 
huge
peak in memory usage on startup ... the amount of swap space consumed by 
such
a program is equal to its peak usage, so if you have lots of these 
programs
on your system you can run out of swap space even though you have plenty 
of
memory to run the programs in a steady state.

The best solution to this is to re-code to reduce the peak memory usage
(often simply creating and destroying autorelease pools more frequently
will do this) - the alternative is to use a larger disk partition.