Par ailleurs, le copy-on-write ne peut fonctionner sur une granularité inférieure à une page (disons 4Ko sur la plupart des architectures). Si ne serait-ce qu'un octet change (par exemple parce que le GC fait un tour dans le coin et pose un flag), la page est départagée.
L'allocation mémoire ne se fait jamais octet par octet, qu'il s'agisse de langages à ramasse miettes (GC) — comme OCaml, Scheme, pour ne citer que mes préférés — ou du C. Chacun de ces langages a son propre système de gestion de la mémoire qui réserve de la mémoire de façon surabondante puis la fournit à l'utilisateur (le programme, client de l'OS) selon ses besoins. C'est en particulier ce qui fait malloc(3) sur beaucoup d'implémentations.
C'est aussi ce qui fait croire, de façon fort erronée, que les langages à GC utilisent beaucoup de mémoire. Sur les OS modernes — comme FreeBSD ou Linux depuis le i386 — le processus accède à une mémoire virtuelle. Un processus réserve de la mémoire virtuelle, et peut demander avec succès plus de mémoire que la mémoire physique (RAM + CACHE) disponible. L'OS répond par une promesse d'allocation mais ne réservera de la mémoire physique que si la mémoire est effectivement utilisée, lue ou écrite par exemple.
Ensuite l'OS ne gère pas la mémoire physique octet par octet, mais probablement page par page, donc avec une certaine granularité: la taille finale du grain est un équilibre entre la complexité des algorithmes d'allocation de mémoire (recherche d'un bloc de la bonne taille) et la mémoire gaspillée à cause de la granularité.
Par exemple si la granularité était de 1 octet, la taille de la carte mémoire et le temps de recherche deviendraient plus important que ceux observés aujourd'hui; si la granularité était de 1Go, ces dernières opérations iraient assez vite mais peu de processus pourraient cohabiter simultanément dans la RAM!
Ceci dit, c'est orthogonal avec la question des fuites mémoires (le copy-on-write n'y peut a priori rien).
Les langages à GC évitent en principe les fuites de mémoire, mais l'utilisation de ces outils n'est pas sans piège, puisque pour chaque profil d'utilisation de la RAM les paramètres du GC doivent être ajustés. Et puis même si la fuite mémoire comme on la connaît en C est techniquement impossible, cela n'empêche pas un programmeur distrait de saturer la mémoire de son système en continuant d'utiliser des variables qui ne sont plus réellement utiles.
[^] # Re: Firefox 9
Posté par Michaël (site web personnel) . En réponse à la dépêche Firefox 8 est disponible. Évalué à 3.
L'allocation mémoire ne se fait jamais octet par octet, qu'il s'agisse de langages à ramasse miettes (GC) — comme OCaml, Scheme, pour ne citer que mes préférés — ou du C. Chacun de ces langages a son propre système de gestion de la mémoire qui réserve de la mémoire de façon surabondante puis la fournit à l'utilisateur (le programme, client de l'OS) selon ses besoins. C'est en particulier ce qui fait
malloc(3)sur beaucoup d'implémentations.C'est aussi ce qui fait croire, de façon fort erronée, que les langages à GC utilisent beaucoup de mémoire. Sur les OS modernes — comme FreeBSD ou Linux depuis le i386 — le processus accède à une mémoire virtuelle. Un processus réserve de la mémoire virtuelle, et peut demander avec succès plus de mémoire que la mémoire physique (RAM + CACHE) disponible. L'OS répond par une promesse d'allocation mais ne réservera de la mémoire physique que si la mémoire est effectivement utilisée, lue ou écrite par exemple.
Ensuite l'OS ne gère pas la mémoire physique octet par octet, mais probablement page par page, donc avec une certaine granularité: la taille finale du grain est un équilibre entre la complexité des algorithmes d'allocation de mémoire (recherche d'un bloc de la bonne taille) et la mémoire gaspillée à cause de la granularité.
Par exemple si la granularité était de 1 octet, la taille de la carte mémoire et le temps de recherche deviendraient plus important que ceux observés aujourd'hui; si la granularité était de 1Go, ces dernières opérations iraient assez vite mais peu de processus pourraient cohabiter simultanément dans la RAM!
Les langages à GC évitent en principe les fuites de mémoire, mais l'utilisation de ces outils n'est pas sans piège, puisque pour chaque profil d'utilisation de la RAM les paramètres du GC doivent être ajustés. Et puis même si la fuite mémoire comme on la connaît en C est techniquement impossible, cela n'empêche pas un programmeur distrait de saturer la mémoire de son système en continuant d'utiliser des variables qui ne sont plus réellement utiles.