[LUGA] Mit freundlicher Unterstützung von:
Linux New Media AG

Mail Thread Index


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

Re: [luga] Neue C-Lib



>>>>> "bp" == Bernd Petrovitsch <bernd@jupiter.ict.tuwien.ac.at>
>>>>> wrote the following on Mon, 26 Jan 1998 14:03:24 +0100

bp> Hi all !

bp> Hmm, malloc() gibt den Speicher nie an das Betriebssystem zurueck.
bp> Das funktioniert anders (hjp und ER moegen mich korrigieren, wenn es 
bp> nicht ganz stimmt) :
bp> 1) Wenn ein Prozess angelegt wird, bekommt er einen (virtuellen) 
bp> Adressraum zugewiesen.
bp> 2) Wenn der Prozess stirbt/terminiert/gekillt -9/ ... wird, wird der 
bp> gesamte Adressraum wieder zurueckgegeben.
bp> 3) Dazwischen kann der Prozess mit den zugeteilten Speicher, machen 
bp> was er aill (und kann).
bp> 3.1) malloc(), free(), u.ae. sind lediglich Teile einer 
bp> standardisierten Library (der C-Library - no na), die das Programm 
bp> verwendet.
bp> 3.2) Jedem, der Lust und Laune hat, kann sich seine eigene 
bp> Heapverwaltung schreiben und verwenden.

Also malloc() und free().
Im prinzip gibt's dafuer 2 moeglichkeiten.
1) der brk() system-call. mit brk gibt man die neue maximale
(hoechste, wenn der heap nach oben wachst) virtuelle addresse an, die
fuer den prozess ein gueltiges memory mapping hat (virtual->physikalisch).
wenn der parameter fuer brk() _kleiner_ als die momentane hoechste
gueltige adresse ist, wird das mapping das daruber liegt von diesem
prozess entfernt. (ein anderer prozess kann auch noch ein mapping
drauf haben [mmap() des /proc/<pid>/mem files], aber das ist eher
esoterisch, aber fuer debugger ganz interessant).

Wenn die malloc()/free implementierung entdeckt, dass speicher
freigegeben wird, der ganz am ende des heap's liegt, wird dieser
wieder freigegeben.

2)mmap() system-call. Mit mmap() kann ich ein sogentanntes private
mapping entweder von /dev/zero (dann ist der speicher
automatisch) mit 0 initialisiert), oder ein ANONYMOUS_MAP machen (dann 
ist der speicher nicht initialisiert). mit munmap() kann ich diesen
speciher wieder freigeben. Malloc()->mmap() und free()->munmap()
klingt zwar gut, ist aber etwas langsam Syscall overhead. Also
allokiert malloc() z.B. 5 pages und wenn mit free() alle 5 pages
wieder frei gweworden sind, wird ein munmap() darauf gemacht (so
aehnlich funktioniert auch der kernel slab allocator).


So nun zur glic.

glibc verwendet brk() und nicht mmap(). die anwort ist also: it
depends(ob der ge-free()'te speciher am ende heap's lag oder nicht,
und ob die malloc() implementiuerung findet, mit brk() den heap
aendern zu muessen. Es gibt aber immer die options das malloc() der
libc-5 mit LD_PRELOAD z.B. zu verwenden.





powered by LINUX the choice of a gnu generation
linux user group austria;
Suche
Suche
Letzte Änderung:
webmaster@luga.at
September 2010