Re: [gtk-list] Re: how can I trust glib when it has so manymemleaks?

["David C. Hoos, Sr." <david c hoos sr ada95 com>]

-----Original Message-----
From: Ionutz Borcoman <borco@borco-ei.eng.hokudai.ac.jp>
To: gtk-list@redhat.com <gtk-list@redhat.com>
Date: Thursday, March 18, 1999 12:43 AM
Subject: [gtk-list] Re: how can I trust glib when it has so manymemleaks?


>Havoc Pennington wrote:
>>
>> No, Unix-ish systems won't let you do that. All the memory is freed by the
>> operating system when the program is terminated. However the memory is
>> never explicitly freed by the program itself, and this is what ccmalloc
>> checks.
>
>Please detail one thing here: memory is alocated by my program using
>glib. You say UNIX will free  all the memory. Why isn't it freeing the
>memory allocated by glib also ? What is the use of ccmalloc if memory is
>freed by system when my program finishes ? Just to ensure that my
>program doesn't grow too much while running ?
>
Exactly,

A process has a finite memory space -- 4 Gb. in the case of 32-bit-address
systems like Linux, and generally only half of that is available to the
process's user space.  In addition, operating environments often further
restrict the resources available to a given process.  The total amount of
memory available to all users of a multi-user system is limited to the amount
of RAM plus the amount of swap space.

Thus, insuring that a program does not grow without limit is a necessity for
real programs, and hence the value of tools like ccmalloc.

In addition, the technique of allocating a chunk of memory to be reused by an
allocator/deallocator within a library is quite common, inasmuch as while
malloc() and free() must be general-purpose, the special-purpose
allocator/deallocator of a library has specialized knowledge about the needs
of the library, and hence, can do a better job at less cost (both time and
space).

Furthermore, even if a program using malloc()/free() does the right thing,
memory can become fragmented -- i.e., there can be plenty of free space, but
in chunks too small to satisfy a particular request.  Memory pools used by a
library can guarantee no fragmentation with appropriate
allocation/deallocation schemes, precisely because the special-purpose library
designer knows what the maximum allocation request size can be, and the
designer of a malloc()/free() in a general-purpose library cannot.

I hope this helps.

David C. Hoos, Sr.