Est-ce que free () démande la memory d'un process?

J'exécute un programme C sur le kernel Linux 2.6.16. Je ne pense pas qu'il y ait des memory leaks dans mon programme mais la consommation de memory pour le programme rest stable après certaines opérations et ne diminue pas. J'utilise la command 'ps v' pour surveiller la valeur RSS de mon programme.

L'outil du massif de valgrind montre qu'une grande partie du tas est allouée par mmap dans mon process. Mais selon le code, ces allocations auraient dû être libérées après les opérations. Est-ce parce que la memory libérée est toujours mappée et / ou consortingbue encore à la valeur RSS du process?

Tout aperçu sera très apprécié!

Ci-dessous est tiré du rapport du massif de valgrind. Note J'ai activé l'option –pages-en-tas pour l'outil massif pour mesurer toutes les memorys utilisées par le programme.

-------------------------------------------------------------------------------- n time(i) total(B) useful-heap(B) extra-heap(B) stacks(B) -------------------------------------------------------------------------------- 85 701,483,989,262 173,576,192 173,576,192 0 0 86 704,352,949,469 173,367,296 173,367,296 0 0 87 707,582,275,643 173,367,296 173,367,296 0 0 88 710,536,145,814 173,367,296 173,367,296 0 0 100.00% (173,367,296B) (page allocation syscalls) mmap/mremap/brk, --alloc-fns, etc. ->53.40% (92,581,888B) 0x649248B: mmap (in /lib64/tls/libc.so.6) | ->41.13% (71,303,168B) 0x6446D85: _int_malloc (in /lib64/tls/libc.so.6) | | ->39.31% (68,157,440B) 0x6448D62: calloc (in /lib64/tls/libc.so.6) ......[my own functions are omitted] ->35.28% (61,157,376B) 0x400F51B: mmap (in /lib64/ld-2.3.3.so) | ->28.81% (49,954,816B) 0x4004CE8: _dl_map_object_from_fd (in /lib64/ld-2.3.3.so) | | ->28.81% (49,954,816B) 0x400636B: _dl_map_object (in /lib64/ld-2.3.3.so) | | ->18.89% (32,755,712B) 0x400AB42: openaux (in /lib64/ld-2.3.3.so) | | | ->18.89% (32,755,712B) 0x400AF7C: _dl_catch_error (in /lib64/ld-2.3.3.so) | | | ->18.89% (32,755,712B) 0x4009FCF: _dl_map_object_deps (in /lib64/ld-2.3.3.so) | | | ->18.89% (32,755,712B) 0x40021FD: dl_main (in /lib64/ld-2.3.3.so) | | | ->18.89% (32,755,712B) 0x400E7F6: _dl_sysdep_start (in /lib64/ld-2.3.3.so) | | | ->18.89% (32,755,712B) 0x4001477: _dl_start (in /lib64/ld-2.3.3.so) | | | ->18.89% (32,755,712B) 0x4000CF6: ??? (in /lib64/ld-2.3.3.so) | | | ->18.89% (32,755,712B) 0x0: ??? | | | ->18.89% (32,755,712B) 0x7FF0003D5: ??? | | | ->18.89% (32,755,712B) 0x7FF0003E4: ??? | | | ...... 

La fonction C-library free() peut, mais ne doit pas nécessairement, returnner la memory au kernel.

Certaines implémentations de malloc() déplacent la limite entre «tas» et l'espace d'adresse autrement inutilisé (la «rupture du système») via l'appel système sbrk() , puis dissortingbuent des parties plus petites de ces grandes allocations. Sans get chaque élément plus petit désalloué, free() ne peut pas vraiment returnner la memory à l'OS.

Cette même raison s'applique aux implémentations malloc() qui n'utilisent pas sbrk(2) , mais qui utilisent peut-être mmap("/dev/zero") ou quelque chose. Je ne trouve pas de reference, ou un autre de la BSD utilisé mmap() cette façon pour get des pages de memory. Néanless, free() ne peut pas renvoyer une page au operating system à less que chaque sous-allocation ne soit libérée par le programme.

Certaines implémentations malloc() renvoient de la memory au système: ChorusOS (?) L'a apparemment fait. Il n'est pas clair si elle a déplacé la pause du système, ou munmap()'ed pages munmap()'ed .

Voici un article sur un allocateur de memory qui améliore les performances en «abandonnant agressivement des pages libres au gestionnaire de memory virtuelle». Diaporama pour une présentation sur l'allocateur.