mmap (lorsqu'il est utilisé avec MAP_ANONYMOUS ) alloue un morceau de RAM qui peut être placé n'importe où dans l'espace d'adressage virtuel du processus, et qui peut être désalloué plus tard (avec munmap ) indépendamment de toutes les autres allocations.
brk change l'adresse de fin d'une seule "arène" contiguë de l'espace d'adressage virtuel :si cette adresse est augmentée, elle alloue plus de mémoire à l'arène, et si elle est diminuée, elle libère la mémoire à la fin de l'arène. Par conséquent, la mémoire allouée avec brk ne peut être renvoyé au système d'exploitation que lorsqu'une plage continue d'adresses à la fin de l'arène n'est plus nécessaire au processus.
Utilisation de brk pour les petites allocations, et mmap pour les grandes allocations, est une heuristique basée sur l'hypothèse que les petites allocations sont plus susceptibles d'avoir toutes la même durée de vie, tandis que les grandes allocations sont plus susceptibles d'avoir une durée de vie qui n'est pas corrélée à la durée de vie des autres allocations. Ainsi, les grosses allocations utilisent la primitive système qui permet de les désallouer indépendamment de toute autre chose, et les petites allocations utilisent la primitive qui ne le fait pas.
Cette heuristique n'est pas très fiable. La génération actuelle de malloc les implémentations, si je me souviens bien, a complètement abandonné brk et utilise mmap pour tout. Le malloc l'implémentation que je soupçonne que vous regardez (celle de la bibliothèque GNU C, basée sur vos balises) est très ancienne et continue principalement d'être utilisée car personne n'est assez courageux pour prendre le risque de l'échanger contre quelque chose de plus récent qui va probablement mais pas certainement va mieux.
alors pourquoi malloc appelle mmap lorsqu'il s'agit d'allouer une grande taille de mémoire ?
La réponse courte est pour une meilleure efficacité sur les nouvelles implémentations de Linux et les algorithmes d'allocation de mémoire mis à jour qui les accompagnent. Mais gardez à l'esprit qu'il s'agit d'un sujet très dépendant de l'implémentation, et que les tenants et les aboutissants varieraient considérablement selon les versions et les saveurs du système d'exploitation Linux spécifique en cours de discussion.
Voici un article assez récent concernant les parties de bas niveau mmap() et brk() jouer dans l'allocation de mémoire Linux. Et, un article pas si récent, mais toujours pertinent du Linux Journal qui inclut du contenu très pertinent pour le sujet ici, y compris ceci :
Pour les requêtes très volumineuses, malloc() utilise l'appel système mmap() pour trouver de l'espace mémoire adressable. Ce processus permet de réduire les effets négatifs de la fragmentation de la mémoire lorsque de grands blocs de mémoire sont libérés mais verrouillés par des blocs plus petits, plus récemment alloués, situés entre eux et la fin de l'espace alloué. Dans ce cas, en effet, si le bloc avait été alloué avec brk(), il serait resté inutilisable par le système même si le processus l'avait libéré.
(c'est moi qui souligne)
Concernant brk() :
d'ailleurs, "...mmap() n'existait pas dans les premières versions d'Unix. brk() était le seul moyen d'augmenter la taille du segment de données du processus à ce moment-là. La première version d'Unix avec mmap() était SunOS au milieu des années 80, la première version open-source était BSD-Reno en 1990. ". Depuis lors, la mise en œuvre moderne des algorithmes d'allocation de mémoire a été refactorisée avec de nombreuses améliorations, réduisant considérablement la nécessité pour eux d'inclure l'utilisation de brk() .