L'allocation de mémoire est-elle un appel système ? Par exemple, malloc et new . Le tas est-il partagé par différents processus et géré par le système d'exploitation ? Qu'en est-il du tas privé ? Si l'allocation de mémoire dans le tas est gérée par le système d'exploitation, quel est le coût de cette gestion ?
J'aimerais également avoir des liens vers des endroits où je peux en savoir plus sur ce sujet.
En général, malloc et new n'effectuent pas d'appel système à chaque invocation. Cependant, ils utilisent un mécanisme de niveau inférieur pour allouer de grandes pages de mémoire. Sous Windows, le mécanisme de niveau inférieur est VirtualAlloc() . Je crois que sur les systèmes POSIX, c'est un peu l'équivalent de mmap() . Tous deux effectuent un appel système pour allouer de la mémoire au processus au niveau du système d'exploitation. Les allocations ultérieures utiliseront des parties plus petites de ces grandes pages sans subir d'appel système.
Le tas est normalement interne au processus et n'est pas partagé entre les processus. Si vous en avez besoin, la plupart des systèmes d'exploitation disposent d'une API pour allouer les ressources du tas. Mémoire partagée . Un wrapper portable pour ces API est disponible dans le module Boost.Interprocessus bibliothèque.
Si vous souhaitez en savoir plus sur l'allocation de la mémoire et sa relation avec le système d'exploitation, vous devriez consulter un bon livre sur les systèmes d'exploitation. Je suggère toujours Systèmes d'exploitation modernes par Andrew S. Tanenbaum car il est très facile à lire.
Sur les systèmes Linux, brk(2) et sbrk(2) sont utilisés aux côtés de mmap(2) . Je voudrais également mentionner que l'AOCP Vol. I de Knuth est une excellente référence pour l'allocation de mémoire également.
Cela dépend du runtime. Avec la version 2010 de Visual Studio, les bibliothèques malloc et free appellent directement HapAlloc / HeapFree, avant qu'il y ait un appel système pour chaque allocation. VirtualAlloc est ensuite utilisé par les fonctions Heap.
@Suma : HeapAlloc n'est pas un appel système, et n'effectue pas nécessairement un appel système.
(En supposant un système d'exploitation avec protection de la mémoire. Cela pourrait ne pas être le cas, par exemple dans les dispositifs embarqués).
L'allocation de mémoire est-elle un appel système ?
Pas nécessairement à chaque allocation. Le processus doit appeler le noyau si son tas n'est pas déjà assez grand pour l'allocation demandée, mais les bibliothèques C demandent généralement des morceaux plus grands lorsqu'elles le font, dans le but de réduire le nombre d'appels système.
Le tas est-il partagé par différents processus et géré par le système d'exploitation ? Qu'en est-il du tas privé ?
Le tas n'est pas partagé entre les processus. Il est partagé entre les threads par contre.
Le coût des appels système d'allocation de mémoire du noyau dépend entièrement du système d'exploitation. Comme il s'agit d'une chose très courante, vous pouvez vous attendre à ce qu'elle soit efficace dans des circonstances normales. Les choses se compliquent dans les situations de faible RAM.
Voir la gestion de la mémoire en couches dans Win32.
L'allocation de mémoire est toujours un appel système mais l'allocation se fait sous forme de pages. S'il y a de l'espace disponible dans les pages engagées, le gestionnaire de mémoire allouera l'espace demandé sans changer le mode du noyau. L'avantage de HeapAlloc est qu'il permet un contrôle fin de l'allocation, alors que Virtual Alloc arrondit l'allocation pour une seule page. Cela peut entraîner une utilisation excessive de la mémoire.
Fondamentalement, le tas par défaut et les tas privés sont traités de la même manière, sauf que la taille du tas par défaut est spécifiée au moment de la liaison. La taille du tas par défaut est de 1 Mo et augmente selon les besoins.
Les fonctions d'allocation de mémoire et les instructions du langage comme malloc/free et new/delete ne sont pas des appels système. Malloc \free fait partie du C \C ++ bibliothèque et nouveautés \delete fait partie du système d'exécution C++. Les appels de ces deux éléments peuvent occasionnellement conduire à des appels système. Dans les autres langages, l'allocation de mémoire est implémentée de manière similaire.
En général, la gestion de la mémoire ne peut pas être mise en œuvre sans impliquer le système d'exploitation, car la mémoire est l'une des principales ressources du système et, de ce fait, la gestion globale de la mémoire est assurée par le noyau du système d'exploitation. Mais étant donné que les appels système sont relativement coûteux, les gens essaient de concevoir des langages et des bibliothèques d'allocation de mémoire de manière à minimiser le nombre d'appels système.
Comme je le sais, le tas est une entité intra-processus. Cela signifie que toutes les demandes d'allocation/désallocation de mémoire sont entièrement gérées par le processus lui-même. Le système d'exploitation ne connaît que l'emplacement et la taille du tas et répond à deux types de demandes du système de gestion de la mémoire intra-processus :
add memory page at virtual address X
release memory page from virtual address XLe système de gestion de la mémoire locale demande ces services lorsqu'il décide qu'il n'a pas assez de mémoire dans le pool de mémoire du tas et lorsqu'il décide qu'il a trop de mémoire dans le pool de mémoire du tas. Malgré le fait que l'allocation de mémoire soit généralement conçue de manière à minimiser le nombre d'appels système, elle reste toujours plus chère que l'allocation de mémoire sur la pile. Ceci est dû au fait que l'allocation de mémoire \deallocation Les algorithmes du tas sont beaucoup plus complexes et coûteux que ceux de la pile.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
