Re: [gtk-list] Unix Memory Management : Clearing up a fewmisconceptions (was Re: how can I trust glib when it has so manymemleaks?)

[Ulric Eriksson <ulric edu stockholm se>]

[This is the last one, I promise]

On 18 Mar 1999, Guillaume Laurent wrote:

> (Unix programmers with a clue can skip this one - or proofread it for
> mistakes :-)
> 
> First of all, though a few people in this thread have already
> correctly stated that free() does not release mem to the OS, even more
> people still have this misconception that, when you free() malloc'ed
> memory, it is released to the OS. THIS IS FALSE, under most
> implementations. So, to state things once and for all (yeah right :-) :
> 
> UNDER UNIX, WHEN YOU FREE() MEMORY, IT IS NOT RELEASED TO THE OS. THE
> SIZE OF YOUR PROCESS WON'T EVER SHRINK, IT CAN ONLY INCREASE.

But as usual, this is Unix, and the correct answer is that it depends. No
amount of screaming will make my Sparc release memory, while my PC will.
Both running Linux. The correct conclusion is that no portable assumptions
can be made, except perhaps that the guys who wrote the malloc
implementation(s) were really smart and have surely thought about the
issues. ;-)

This doesn't affect the fragmentation created by allocating memory into
several disjoint pools.

> e.g. :
> 
> ptr = malloc(10 * 1024) ; // Your process size increases by 10K
> free(ptr); // Your process size DOES NOT CHANGE
> ptr = malloc(10 * 1024) ; // Your process size DOES NOT CHANGE either.

Here is the effect of using two allocators which each hang on to every
piece of memory they have ever seen:

ptr = malloc1(10000);	/* process increases by 10K */
free1(ptr);		/* process size doesn't change */
ptr = malloc2(10000);	/* process increases by another 10K */

Ulric