gnupic: Re: [gnupic] gpasm memory leaks


Previous by date: 5 Jun 2007 10:00:44 +0100 Re: [gnupic] gpasm memory leaks, David Barnett
Next by date: 5 Jun 2007 10:00:44 +0100 the best software for manage PICs in Linux, Mario Pisa
Previous in thread: 5 Jun 2007 10:00:44 +0100 Re: [gnupic] gpasm memory leaks, David Barnett
Next in thread:

Subject: Re: [gnupic] gpasm memory leaks
From: Ralph Corderoy ####@####.####
Date: 5 Jun 2007 10:00:44 +0100
Message-Id: <20070605090037.F3511149BED@blake.inputplus.co.uk>

Hi David,

> Actually, until recently I didn't know the OS would clean up the
> memory leaks when you close the program (I've heard AmigaOS actually
> wouldn't).

It's not really cleaning up the memory leaks.  The OS has a concept of a
process, and the resources it's using, and frees those resources for use
by other processes when a process is finished.  This includes normal
memory.  The OS has no concept of malloc() and free() inside the
process;  you probably realise this.

Yes, I've heard a rumour AmigaOS didn't do this.  Also, in most OS there
are types of memory a process can request, e.g. shared memory, that
remain allocated after a process exits by design.

> Would there tend to be a performance improvement one way or the other?

There can be.  Imagine every memory area returned by malloc() has a
couple of words of information before the address it returns.  One might
be the length of the area.  If your program calls free() for this area
then the length has to be read from memory and perhaps, when it's added
back into a "free memory area list" a "next" pointer will be written
into the now freed memory.  This read and write by the processor takes
time, fills process cache lines, perhaps pages in memory from swap
space, etc.  So running through all your data structures freeing them
just before exit() can be a lot more taxing than just exiting allowing
the OS to know all memory pages used by your process are now available.

(Some malloc() implementations may not work like this for the downsides
given, but they used to and some still do.)

> Regardless, if that's a common position and you know of any discussion
> or articles about it, please point me to them.

If you don't mind me saying so, you seem a bit short of experience based
on comments like keeping allocation and deallocation at the same stack
level.  That would possibly suggest using the stack instead of the heap.
A few decent books include

    The C Programming Language, 2 Ed., by Kernighan and Ritchie.
    The Practice of Programming, by Kernighan and Pike.
    The Unix Programming Environment, by Kernighan and Pike.

Cheers,


Ralph.


Previous by date: 5 Jun 2007 10:00:44 +0100 Re: [gnupic] gpasm memory leaks, David Barnett
Next by date: 5 Jun 2007 10:00:44 +0100 the best software for manage PICs in Linux, Mario Pisa
Previous in thread: 5 Jun 2007 10:00:44 +0100 Re: [gnupic] gpasm memory leaks, David Barnett
Next in thread:


Powered by ezmlm-browse 0.20.