Je trouve qu'il manque un aspect et que c'est trompeur.
Il est effectivement possible de rendre de la mémoire pour les autres processus, mais ce n'est pas le cas courant. Cela demande de mapper explicitement de la mémoire, et de la rendre lorsqu'on n'en a plus besoin. Cela demande un artifice qui complexifie le code et ajoute une nouvelle source de bugs. (d'après la page de malloc(3) c'est effectivement le cas avec une glibc moderne, un kernel >= 4.7 et pour les allocations unitaires au dessus de 128k).
Au niveau OS, les programme en C allouent leur mémoire dans un seul segment appelé le tas, dont la taille est ajustée avec sbrk(2). Cette taille de tas est augmenté lorsque la mémoire libre n'est pas suffisante; a ma connaissance elle n'est jamais diminuée car cela nécessiterait une défragmentation de l'espace mémoire du processus.
Il y a dix ans (la dernière fois que j'ai testé), le GC Java fonctionnait également sans jamais rendre de mémoire (la consommation augmentait jusqu'à la valeur limite de Xmx). Un GC générationnel devrait pouvoir rendre de la mémoire, mais serait obligé de ré-allouer quasiment la même chose au prochain passage. Je doute qu'il le fasse.
En Go, j'ignore comment ça se passe, mais je serais surpris que le GC s'amuse à rendre de la mémoire en fonctionnement normal.
[^] # Re: Le but d’un GC n’a jamais été les performances
Posté par Sébastien Koechlin . En réponse au journal Performances et GC : détruisons les mythes. Évalué à 8.
Je trouve qu'il manque un aspect et que c'est trompeur.
Il est effectivement possible de rendre de la mémoire pour les autres processus, mais ce n'est pas le cas courant. Cela demande de mapper explicitement de la mémoire, et de la rendre lorsqu'on n'en a plus besoin. Cela demande un artifice qui complexifie le code et ajoute une nouvelle source de bugs. (d'après la page de malloc(3) c'est effectivement le cas avec une glibc moderne, un kernel >= 4.7 et pour les allocations unitaires au dessus de 128k).
Au niveau OS, les programme en C allouent leur mémoire dans un seul segment appelé le tas, dont la taille est ajustée avec sbrk(2). Cette taille de tas est augmenté lorsque la mémoire libre n'est pas suffisante; a ma connaissance elle n'est jamais diminuée car cela nécessiterait une défragmentation de l'espace mémoire du processus.
Il y a dix ans (la dernière fois que j'ai testé), le GC Java fonctionnait également sans jamais rendre de mémoire (la consommation augmentait jusqu'à la valeur limite de Xmx). Un GC générationnel devrait pouvoir rendre de la mémoire, mais serait obligé de ré-allouer quasiment la même chose au prochain passage. Je doute qu'il le fasse.
En Go, j'ignore comment ça se passe, mais je serais surpris que le GC s'amuse à rendre de la mémoire en fonctionnement normal.