X-Git-Url: https://git.llucax.com/z.facultad/75.00/informe.git/blobdiff_plain/7bf015e28150f252101e698079d52839d2a518c8..22cb44a8463f90a10ca59340382c1d104b2cda74:/source/gc.rst

diff --git a/source/gc.rst b/source/gc.rst
index a1eb360..a221059 100644
--- a/source/gc.rst
+++ b/source/gc.rst
@@ -183,9 +183,9 @@ lenguajes de programación que requieran un recolector de basura conservativo.
 Por último, siendo que el recolector de basura es parte del programa de forma
 indirecta, es común ver en la literatura que se direfencia entre
 2 partes del programa, el recolector de basura y el programa en sí. Dado que
-  para el recolector de basura, lo único que interesa conocer del programa en
-  sí son los cambios al grafo de conectividad de las celdas, normalmente se lo
-  llama *mutator* (mutador).
+para el recolector de basura, lo único que interesa conocer del programa en
+sí son los cambios al grafo de conectividad de las celdas, normalmente se lo
+llama *mutator* (mutador).
 
 
 
@@ -1687,7 +1687,16 @@ utiliza para asignar nuevas celdas de forma lineal, asumiendo un *heap*
 contiguo, incrementando un puntero (ver figura :vref:`fig:gc-copy`).  Esto se
 conoce como *pointer bump allocation* y es, probablemente, la forma más
 eficiente de asignar memoria (tan eficiente como asignar memoria en el
-*stack*).
+*stack*). Esto permite además evitar el problema de la *fragmentación* de
+memoria [#gcfrag]_ que normalmente afectan a los otros algoritmos clásicos (o
+sus *low level allocators*).
+
+.. [#gcfrag] La *fragmentación* de memoria sucede cuando se asignan objetos
+   de distintos tamaños y luego libera alguno intermedio, produciendo
+   *huecos*. Estos *huecos* quedan inutilizables hasta que se quiera
+   asignar un nuevo objeto de tamaño igual al *hueco* (o menor). Si esto no
+   sucede y se acumulan muchos *huecos* se dice que la memoria está
+   *fragmentada*.
 
 .. fig:: fig:gc-copy