Les accès mémoire sont gérés par l'OS. Celui-ci exporte des appels système pour réserver de l'espace mémoire. Les applis ne font qu'appel à ces appels systèmes soit directement soit au travers de fonctions de librairies.
Par contre, le choix de ces appels et quand peut permettre des améliorations de performance. Ainsi par exemple, sous Linux et d'autres Unix il est plus "performant" de faire appel à mmap une fois pour toute pour allouer toute la mémoire qu'aura besoin l'application et de l'utiliser pour les variables à allouer dans le tas que d'utiliser de multiples malloc.
Dans ce cas, par exemple, les langages de haut niveau qui gèrent automatiquement la mémoire sont dotés d'algorithmes (soit le runtime soit le compilateur) très poussés pour gérer de façon à peu près optimale la mémoire (pour les compilateurs par une analyse sémentique en une ou plusieurs passes).
De la même façon, depuis les années 80 (le garbadge collecting existe bien avant ces années), les algorithmes et les techniques de garbadge collecting se sont bcp améliorés.
Aussi, de nos jours, les problématiques de gestion de mémoire sont moins pertinantes qu'il y a quelque temps et ne méritent plus que l'on s'y consacre autant de temps avec des langages de bas niveau (excepté prog système, embarqué, noyau, ...).
[^] # Re: La memoire goulot d'etranglement
Posté par Miguel Moquillon (site web personnel) . En réponse au journal Comment résoudre la "crise du logiciel" ?. Évalué à 3.
Par contre, le choix de ces appels et quand peut permettre des améliorations de performance. Ainsi par exemple, sous Linux et d'autres Unix il est plus "performant" de faire appel à mmap une fois pour toute pour allouer toute la mémoire qu'aura besoin l'application et de l'utiliser pour les variables à allouer dans le tas que d'utiliser de multiples malloc.
Dans ce cas, par exemple, les langages de haut niveau qui gèrent automatiquement la mémoire sont dotés d'algorithmes (soit le runtime soit le compilateur) très poussés pour gérer de façon à peu près optimale la mémoire (pour les compilateurs par une analyse sémentique en une ou plusieurs passes).
De la même façon, depuis les années 80 (le garbadge collecting existe bien avant ces années), les algorithmes et les techniques de garbadge collecting se sont bcp améliorés.
Aussi, de nos jours, les problématiques de gestion de mémoire sont moins pertinantes qu'il y a quelque temps et ne méritent plus que l'on s'y consacre autant de temps avec des langages de bas niveau (excepté prog système, embarqué, noyau, ...).