Bah cela dépend du style de gc utilisé mais il est tout à fait possible de compacter la mémoire après un cycle du gc (p.e. stop-and-copy). Aussi, à partir du moment où l'on utilise un gc, on ne peut pas vraiment dire que c'est «une couche au dessus» étant donné le couplage fort qu'il peut y avoir entre l'allocateur et le gc. Ceci dit, il est plus probable qu'ils ne se concentrent qu'à changer d'allocateur (comme l'explique l'auteur de ce blog) afin d'éviter les fragmentations en amont, à l'instar des devs de la glib avec leur slice allocator.
Secondo, ce que dit le gars c'est qu'une partie de la fragmentation due aux très petites allocations (dans le tas) peut être justement évitée en faisant des allocations sur la pile. Effectivement, un gc se fout des allocs sur la pile mais il est hors de question de tout allouer sur la pile ! Je ne t'apprends sans doute rien mais je n'arrivais pas à comprendre le sens de ta remarque...
[^] # Re: ah, la mémoire...
Posté par benja . En réponse au journal Firefox 3 béta 2. Évalué à 1.
Secondo, ce que dit le gars c'est qu'une partie de la fragmentation due aux très petites allocations (dans le tas) peut être justement évitée en faisant des allocations sur la pile. Effectivement, un gc se fout des allocs sur la pile mais il est hors de question de tout allouer sur la pile ! Je ne t'apprends sans doute rien mais je n'arrivais pas à comprendre le sens de ta remarque...