[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: KConfig again
From:       Christian Esken <c.esken () cityweb ! de>
Date:       1999-05-16 12:12:27
[Download RAW message or body]

On Sun, 16 May 1999 pbrown@redhat.com wrote:
>On Sun, 16 May 1999, Steffen Hansen wrote:
>
>> Maybe the app should decide for itself if entries should be cached in RAM
>> (in a QMap).
>
>We have talked a little more and now it seems like putting the entries in
>a size limited QCache might be a good idea, which the cache flushed out
>periodically.
>
>However, I am under the impression that once an application has allocated
>memory, even if it frees it, it doesn't go back into the system memory
>pool.  It keeps it until it exits.  Isn't this the case in the majority of
>UNIX systems?

No. You have to differ between kernel MM and libc MM.
This behaviour would actually be quite "stupid". Just think
about the situation where you have scanned a 60MB picture.
Now your scanner program would hog 60MB even after free()Žing
the memory piece.

Your observation is still not 100% untrue. It comes from the fact that
you can only can allocate/free full memory pages (OS and MM hardware
dependent, typically 2K-16K in size). To handle this problem, libc does
some tricks:

libc has an internal "memory pool", from which it handles all malloc()
and free() requests. If libc does not have a big enough memory
piece around for your malloc() call, it requests new memory from the
kernel. If you free() memory, libc first marks the memory as unused.

Under certain conditions (could be something like "full page unused"),
the memory gets truely freeŽd.



Christian

-- 
Is Unix ready for the desktop? See http://www.kde.org

The                              Christian Esken
|/  Desktop                      KDE Developer
|\  Environment                  esken@kde.org

KDE - The net transparent free Unix Desktop for everyone

[prev in list] [next in list] [prev in thread] [next in thread]