discuss-gnustep
[Top][All Lists]
Advanced

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

Re: Problem with NSAutoreleasePool in GNUstep


From: Pascal Bourguignon
Subject: Re: Problem with NSAutoreleasePool in GNUstep
Date: Mon, 3 Dec 2001 19:03:10 +0100 (CET)

You can bypass the sbrk calls by allocating the temporary objects into
a separate NSZone. If I  read the source correctly, the implementation
in GNUstep  of NSZone uses  ultimately objc_malloc.  On Mach,  it used
memory mapping. You can implement your own memory mapping NSZone (have
a look at 'gnustep/core/base/Sources/NSZone.m') using mmap/munmap.


Richard Frith-Macdonald <richard@brainstorm.co.uk> wrote:
> 
> 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.
> 


-- 
__Pascal_Bourguignon__              (o_ Software patents are endangering
()  ASCII ribbon against html email //\ the computer industry all around
/\  and Microsoft attachments.      V_/ the world http://lpf.ai.mit.edu/
1962:DO20I=1.100  2001:my($f)=`fortune`;  http://petition.eurolinux.org/

-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/IT d? s++:++(+++)>++ a C+++  UB+++L++++$S+X++++>$ P- L+++ E++ W++
N++ o-- K- w------ O- M++$ V PS+E++ Y++ PGP++ t+ 5? X+ R !tv b++(+)
DI+++ D++ G++ e+++ h+(++) r? y---? UF++++
------END GEEK CODE BLOCK------



reply via email to

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