X-Git-Url: https://git.llucax.com/z.facultad/75.00/informe.git/blobdiff_plain/172c35bcbc4fd39672a8a4df0d42f9dccb197c91..6e74d0a5708f7882c1fe837ad413974db3275012:/source/gc.rst?ds=sidebyside

diff --git a/source/gc.rst b/source/gc.rst
index d771f7a..6abc764 100644
--- a/source/gc.rst
+++ b/source/gc.rst
@@ -5,82 +5,78 @@
    ESTADO: TERMINADO
 
 
-.. _ref_gc:
+.. _gc:
 
 Recolección de basura
 ============================================================================
 
 
 
-.. _ref_gc_intro:
+.. _gc_intro:
 
 Introducción
 ----------------------------------------------------------------------------
 
-*Recolección de basura* se refiere a la recuperación automática de memoria
-del *heap* [#gcheap]_ una vez que el programa ha dejado de hacer referencia
-a ella (y por lo tanto, ha dejado de utilizarla).
+*Recolección de basura* se refiere a la recuperación automática de memoria del
+*heap* [#gcheap]_ una vez que el programa ha dejado de hacer referencia a ella
+(y por lo tanto, ha dejado de utilizarla).
 
 .. [#gcheap] *Heap* es un área de memoria que se caracteriza por ser
    dinámica (a diferencia del área de memoria estática que está disponible
    durante toda la ejecución de un programa). Un programa puede reservar
-   memoria en tiempo de ejecución según sea necesario y liberarla cuando ya
-   no la necesita. A diferencia del *stack*, la duración de la *reserva* no
-   está atada a un bloque de código.
-
-A medida que el tiempo pasa, cada vez los programas son más complejos y es
-más compleja la administración de memoria. Uno de los aspectos más
-importantes de un recolector de basura es lograr un mayor nivel de
-abstracción y modularidad, dos conceptos claves en la ingeniería de
-software [JOLI96]_. En particular, al diseñar o programar bibliotecas, de
-no haber un recolector de basura, **la administración de memoria pasa a ser
-parte de la interfaz**, lo que produce que los módulos tengan un mayor
-grado de acoplamiento.
-
-Además hay una incontable cantidad de problemas asociados al manejo
-explícito de memoria que simplemente dejan de existir al utilizar un
-recolector de basura. Por ejemplo, los errores en el manejo de memoria
-(como *buffer overflows* [#gcbuff]_ o *dangling pointers* [#gcdang]_) son
-la causa más frecuente de problemas de seguridad [BEZO06]_.
+   memoria en tiempo de ejecución según sea necesario y liberarla cuando ya no
+   la necesita. A diferencia del *stack*, la duración de la *reserva* no está
+   atada a un bloque de código.
+
+A medida que el tiempo pasa, cada vez los programas son más complejos y es más
+compleja la administración de memoria. Uno de los aspectos más importantes de
+un recolector de basura es lograr un mayor nivel de abstracción y modularidad,
+dos conceptos claves en la ingeniería de software [JOLI96]_. En particular, al
+diseñar o programar bibliotecas, de no haber un recolector de basura, **la
+administración de memoria pasa a ser parte de la interfaz**, lo que produce
+que los módulos tengan un mayor grado de acoplamiento.
+
+Además hay una incontable cantidad de problemas asociados al manejo explícito
+de memoria que simplemente dejan de existir al utilizar un recolector de
+basura. Por ejemplo, los errores en el manejo de memoria (como *buffer
+overflows* [#gcbuff]_ o *dangling pointers* [#gcdang]_) son la causa más
+frecuente de problemas de seguridad [BEZO06]_.
 
 .. [#gcbuff] Un *buffer overflow* (*desbordamiento de memoria* en
-   castellano) se produce cuando se copia un dato a un área de memoria que
-   no es lo suficientemente grande para contenerlo. Esto puede producir que
-   el programa sea abortado por una violación de segmento, o peor,
-   sobreescribir un área de memoria válida, en cuyo caso los resultados son
-   impredecibles.
+   castellano) se produce cuando se copia un dato a un área de memoria que no
+   es lo suficientemente grande para contenerlo. Esto puede producir que el
+   programa sea abortado por una violación de segmento, o peor, sobreescribir
+   un área de memoria válida, en cuyo caso los resultados son impredecibles.
 
 .. [#gcdang] Un *dangling pointer* (*puntero colgante* en castellano) es un
-   puntero que apunta a un área de memoria inválida. Ya sea porque el
-   elemento apuntado no es el mismo tipo o porque la memoria ya ha sido
-   liberada. Al ser desreferenciado, los resultados son impredecibles, el
-   programa podría abortarse por una violación de segmento o podrían pasar
-   peores cosas si el área de memoria fue realocada para almacenar otro
-   objeto.
+   puntero que apunta a un área de memoria inválida. Ya sea porque el elemento
+   apuntado no es el mismo tipo o porque la memoria ya ha sido liberada. Al
+   ser desreferenciado, los resultados son impredecibles, el programa podría
+   abortarse por una violación de segmento o podrían pasar peores cosas si el
+   área de memoria fue re-asignada para almacenar otro objeto.
 
 La recolección de basura nació junto a Lisp_ a finales de 1950 y en los
-siguientes años estuvo asociada principalmente a lenguajes funcionales,
-pero en la actualidad está presente en prácticamente todos los lenguajes de
+siguientes años estuvo asociada principalmente a lenguajes funcionales, pero
+en la actualidad está presente en prácticamente todos los lenguajes de
 programación, de alto o bajo nivel, aunque sea de forma opcional. En los
 últimos 10 años tuvo un gran avance, por la adopción en lenguajes de
 desarrollo rápido utilizados mucho en el sector empresarial, en especial
-Java_, que fue una plataforma de facto para la investigación y desarrollo
-de recolectores de basura (aunque no se limitaron a este lenguaje las
+Java_, que fue una plataforma de facto para la investigación y desarrollo de
+recolectores de basura (aunque no se limitaron a este lenguaje las
 investigaciones).
 
-En las primeras implementaciones de recolectores de basura la penalización
-en la eficiencia del programa se volvía prohibitiva para muchas
-aplicaciones. Es por esto que hubo bastante resistencia a la utilización de
-recolectores de basura, pero el avance en la investigación fue haciendo que
-cada vez sea una alternativa más viable al manejo manual de memoria,
-incluso para apliaciones con altos requerimientos de eficiencia. En la
-actualidad un programa que utiliza un recolector moderno puede ser
-comparable en eficiencia con uno que utiliza un esquema manual. En
-particular, si el programa fue diseñado con el recolector de basura en
-mente en ciertas circunstancias puede ser incluso más eficiente que uno que
-hace manejo explícito de la memoria. Muchos recolectores mejoran la
-localidad de referencia [#gcreflocal]_, haciendo que el programa tenga un
-mejor comportamiento con el caché y la memoria virtual.
+En las primeras implementaciones de recolectores de basura la penalización en
+la eficiencia del programa se volvía prohibitiva para muchas aplicaciones. Es
+por esto que hubo bastante resistencia a la utilización de recolectores de
+basura, pero el avance en la investigación fue haciendo que cada vez sea una
+alternativa más viable al manejo manual de memoria, incluso para apliaciones
+con altos requerimientos de eficiencia. En la actualidad un programa que
+utiliza un recolector moderno puede ser comparable en eficiencia con uno que
+utiliza un esquema manual. En particular, si el programa fue diseñado con el
+recolector de basura en mente en ciertas circunstancias puede ser incluso más
+eficiente que uno que hace manejo explícito de la memoria. Muchos recolectores
+mejoran la localidad de referencia [#gcreflocal]_, haciendo que el programa
+tenga un mejor comportamiento con el caché y la memoria virtual.
 
 .. [#gcreflocal] Localidad de referencia es la medida en que los accesos
    sucesivos de memoria cercana espacialmente son cercanos también en el
@@ -91,11 +87,11 @@ mejor comportamiento con el caché y la memoria virtual.
    (o *working set*) y mejora la probabildad de éxito (*hit rate*).
 
 El recolector de basura debe tener un comportamiento correcto y predecible
-para que sea útil, si el programador no puede confiar en el recolector
-de basura, éste se vuelve más un problema que una solución, porque
-introduce nuevos puntos de falla en los programas, y lo que es peor,
-puntos de falla no controlados por el programador, volviendo mucho más
-difícil la búsqueda de errores.
+para que sea útil, si el programador no puede confiar en el recolector de
+basura, éste se vuelve más un problema que una solución, porque introduce
+nuevos puntos de falla en los programas, y lo que es peor, puntos de falla no
+controlados por el programador, volviendo mucho más difícil la búsqueda de
+errores.
 
 
 
@@ -106,63 +102,62 @@ Conceptos básicos
 Los programas pueden hacer uso principalmente de 4 áreas de memoria:
 
 Registros:
-   Se trata de la memoria más básica de una computadora. Es el área de
-   memoria en la que puede operar realmente el procesador, es extremadamente
-   escasa y generalmente su uso es administrado por el lenguaje de
-   programación (o compilador más específicamente). Excepto en situaciones
-   muy particulares, realizando tareas de muy bajo nivel, un programador
-   nunca manipula los registros explícitamente.
+   Se trata de la memoria más básica de una computadora. Es el área de memoria
+   en la que puede operar realmente el procesador, es extremadamente escasa
+   y generalmente su uso es administrado por el lenguaje de programación (o
+   compilador más específicamente). Excepto en situaciones muy particulares,
+   realizando tareas de muy bajo nivel, un programador nunca manipula los
+   registros explícitamente.
 
 Área de memoria estática:
    Es la forma de memoria más simple que un programador utiliza
    explícitamente. En general las variables globales se almacenan en este
-   área, que es parte inherente del programa y está disponible durante toda
-   su ejecución, por lo tanto nunca cambia su capacidad en tiempo de
-   ejecución. Es la forma más básica de administrar memoria, pero tiene una
-   limitación fundamental: **el tamaño de la memoria tiene que ser conocido
-   en tiempo de compilación**. Los primeros lenguajes de programación solo
-   contaban con este tipo de memoria (además de los registros del
-   procesador).
+   área, que es parte inherente del programa y está disponible durante toda su
+   ejecución, por lo tanto nunca cambia su capacidad en tiempo de ejecución.
+   Es la forma más básica de administrar memoria, pero tiene una limitación
+   fundamental: **el tamaño de la memoria tiene que ser conocido en tiempo de
+   compilación**. Los primeros lenguajes de programación solo contaban con
+   este tipo de memoria (además de los registros del procesador).
 
 *Stack* (pila):
    Los primeros lenguajes de programación que hicieron uso de una pila
    aparecieron en el año 1958 (Algol-58 y Atlas Autocode) y fueron los
-   primeros en introducir estructura de bloques, almacenando las
-   variables locales a estos bloques utilizando una pila [JOLI96]_.
-   Esto permite utilizar recursividad y tener un esquema simple de memoria
-   dinámica. Sin embargo este esquema es muy limitado porque el orden de
-   reserva y liberación de memoria tiene que estar bien establecido. Una
-   celda [#gccelda]_ alocada antes que otra nunca puede ser liberada antes
-   que aquella.
+   primeros en introducir estructura de bloques, almacenando las variables
+   locales a estos bloques utilizando una pila [JOLI96]_.  Esto permite
+   utilizar recursividad y tener un esquema simple de memoria dinámica. Sin
+   embargo este esquema es muy limitado porque el orden de reserva
+   y liberación de memoria tiene que estar bien establecido. Una celda
+   [#gccelda]_ asignada antes que otra nunca puede ser liberada antes que
+   aquella.
 
    .. [#gccelda] En general en la literatura se nombra a una porción de
-      memoria alocada individualmente *celda*, *nodo* u *objeto*
+      memoria asignada individualmente *celda*, *nodo* u *objeto*
       indistintamente. En este trabajo se utilizará la misma nomenclatura
-      (haciendo mención explícita cuando alguno de estos términos se
-      refiera a otra cosa, como al nodo de una lista o a un objeto en el
-      sentido de programación orientada a objetos).
+      (haciendo mención explícita cuando alguno de estos términos se refiera
+      a otra cosa, como al nodo de una lista o a un objeto en el sentido de
+      programación orientada a objetos).
 
 *Heap*:
-   A diferencia del *stack*, el *heap* provee un área de memoria que puede
-   ser obtenida dinámicamente pero sin limitaciones de orden. Es el tipo de
+   A diferencia del *stack*, el *heap* provee un área de memoria que puede ser
+   obtenida dinámicamente pero sin limitaciones de orden. Es el tipo de
    memoria más flexible y por lo tanto el más complejo de administrar; razón
    por la cual existen los recolectores de basura.
 
 La recolección de basura impone algunas restricciones sobre la manera de
 utilizar el *heap*. Debido a que un recolector de basura debe ser capaz de
-determinar el grafo de conectividad de la memoria en uso, es necesario que
-el programa siempre tenga alguna referencia a las celdas activas en los
+determinar el grafo de conectividad de la memoria en uso, es necesario que el
+programa siempre tenga alguna referencia a las celdas activas en los
 registros, memoria estática o *stack* (normalmente denominado *root set*).
 
 Esto implica que una celda sea considerada basura si y sólo si no puede ser
-alcanzada a través del grafo de conectividad que se comienza a recorrer
-desde el *root set*. Por lo tanto, una celda está *viva* si y sólo si su
-dirección de memoria está almacenada en una celda *raíz* (parte del *root
-set*) o si está almacenada en otra celda *viva* del *heap*.
+alcanzada a través del grafo de conectividad que se comienza a recorrer desde
+el *root set*. Por lo tanto, una celda está *viva* si y sólo si su dirección
+de memoria está almacenada en una celda *raíz* (parte del *root set*) o si
+está almacenada en otra celda *viva* del *heap*.
 
-Expresado más formalmente, dada la relación :math:`M \to N`, donde
-:math:`M` es una celda del *heap* o parte del *root set* y :math:`N` es una
-celda del *heap*, definida como:
+Expresado más formalmente, dada la relación :math:`M \to N`, donde :math:`M`
+es una celda del *heap* o parte del *root set* y :math:`N` es una celda del
+*heap*, definida como:
 
 .. math::
 
@@ -176,40 +171,39 @@ El conjunto de celdas vivas (o *live set*) queda determinado por:
       ( \exists r \in Raices / r \to N ) \vee (\exists M \in vivas / M \to N )
    \right\rbrace
 
-Cabe aclarar que esta es una definición conceptual, asumiendo que el
-programa siempre limpia una dirección de memoria almacenada en el *root
-set* o una celda del *heap* cuando la celda a la que apunta no va a ser
-utilizada nuevamente. Esto no es siempre cierto y los falsos positivos que
-esto produce se conoce como un tipo de pérdida de memoria (que es posible
-incluso al utilizar un recolector de basura) llamada pérdida de memoria
-*lógica*. Esto puede no ser evitable (incluso cuando el programador no
-cometa errores) en lenguajes de programación que requieran un recolector de
-basura conservativo.
+Cabe aclarar que esta es una definición conceptual, asumiendo que el programa
+siempre limpia una dirección de memoria almacenada en el *root set* o una
+celda del *heap* cuando la celda a la que apunta no va a ser utilizada
+nuevamente. Esto no es siempre cierto y los falsos positivos que esto produce
+se conoce como un tipo de pérdida de memoria (que es posible incluso al
+utilizar un recolector de basura) llamada pérdida de memoria *lógica*. Esto
+puede no ser evitable (incluso cuando el programador no cometa errores) en
+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).
+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).
 
 
 
-.. _ref_gc_intro_mark:
+.. _gc_intro_mark:
 
 Recorrido del grafo de conectividad
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-El problema de encontrar las celdas *vivas* de un programa se reduce a recorrer
-un grafo dirigido. El grafo se define como:
+El problema de encontrar las celdas *vivas* de un programa se reduce
+a recorrer un grafo dirigido. El grafo se define como:
 
 .. math::
 
    G = (V,A)
 
 Donde :math:`V` es el conjunto de vértices, dado por las celdas de memoria
-y :math:`A` es un conjunto de pares ordenados (aristas), dado por la
-relación :math:`M \rightarrow N` (es decir, los punteros).
+y :math:`A` es un conjunto de pares ordenados (aristas), dado por la relación
+:math:`M \rightarrow N` (es decir, los punteros).
 
 El grafo comienza a recorrerse desde el *root set* y todos los vértices que
 fueron visitados componen el *live set*; el resto de los vértices son
@@ -218,11 +212,10 @@ fueron visitados componen el *live set*; el resto de los vértices son
 Más formalmente, Definimos:
 
 *Camino*:
-   secuencia de vértices tal que cada uno de los vértices tiene una arista
-   al próximo vértice en la secuencia. Todo camino finito tiene un *vértice
-   inicial* y un *vértice final* (llamados en conjunto *vértices
-   terminales*). Cualquier vértice no terminal es denominado *vértice
-   interior*.
+   secuencia de vértices tal que cada uno de los vértices tiene una arista al
+   próximo vértice en la secuencia. Todo camino finito tiene un *vértice
+   inicial* y un *vértice final* (llamados en conjunto *vértices terminales*).
+   Cualquier vértice no terminal es denominado *vértice interior*.
 
    .. math::
 
@@ -240,9 +233,9 @@ Más formalmente, Definimos:
       M \mapsto N \Longleftrightarrow \exists \underset{M \to N}{C} \in G
 
 *Live set*:
-   el conjunto de celdas *vivas* está dado por todos los vértices
-   (:math:`v`) del grafo para los cuales existe una raíz en el *root set*
-   que esté conectada a él.
+   el conjunto de celdas *vivas* está dado por todos los vértices (:math:`v`)
+   del grafo para los cuales existe una raíz en el *root set* que esté
+   conectada a él.
 
    .. math::
 
@@ -264,8 +257,10 @@ Esto es, efectivamente, una partición del *heap* (ver figura
 
 .. fig:: fig:gc-heap-parts
 
-   Distintas partes de la memoria, incluyendo relación entre *basura*,
-   *live set*, *heap* y *root set*.
+   Distintas partes de la memoria *heap*.
+
+   Distintas partes de la memoria, incluyendo relación entre *basura*, *live
+   set*, *heap* y *root set*.
 
    .. digraph:: g1
 
@@ -321,22 +316,22 @@ Esto es, efectivamente, una partición del *heap* (ver figura
 
 
 Al proceso de visitar los vértices *conectados* desde el *root set* se lo
-denomina *marcado*, *fase de marcado* o *mark phase* en inglés, debido
-a que es necesario marcar los vértices para evitar visitar 2 veces el mismo
-nodo en casos de que el grafo contenga ciclos [#gccycle]_. De forma similar
-a la búsqueda, que puede realizarse *primero a lo ancho* (*breadth-first*)
+denomina *marcado*, *fase de marcado* o *mark phase* en inglés, debido a que
+es necesario marcar los vértices para evitar visitar 2 veces el mismo nodo en
+casos de que el grafo contenga ciclos [#gccycle]_. De forma similar a la
+búsqueda, que puede realizarse *primero a lo ancho* (*breadth-first*)
 o *primero a lo alto* (*depth-first*) del grafo, el marcado de un grafo
-también puede realizarse de ambas maneras. Cada una podrá o no tener
-efectos en la eficiencia, en particular dependiendo de la aplicación puede
-convenir uno u otro método para lograr una mejor localidad de referencia.
+también puede realizarse de ambas maneras. Cada una podrá o no tener efectos
+en la eficiencia, en particular dependiendo de la aplicación puede convenir
+uno u otro método para lograr una mejor localidad de referencia.
 
 .. [#gccycle] Un ciclo es un camino donde el *vértice inicial* es el mismo
    que el *vértice final*. Por lo tanto, los *vértices terminales* son
-   completamente arbitrarios, ya que cualquier *vértice interior* puede ser
-   un *vértice terminal*.
+   completamente arbitrarios, ya que cualquier *vértice interior* puede ser un
+   *vértice terminal*.
 
-Un algoritmo simple (recursivo) de marcado *primero a lo alto*  puede ser
-el siguiente (asumiendo que partimos con todos los vértices sin marcar)
+Un algoritmo simple (recursivo) de marcado *primero a lo alto*  puede ser el
+siguiente (asumiendo que partimos con todos los vértices sin marcar)
 [#gcpseudo]_::
 
    function mark(v) is
@@ -350,24 +345,24 @@ el siguiente (asumiendo que partimos con todos los vértices sin marcar)
          mark(r)
 
 .. [#gcpseudo] Para presentar los algoritmos se utiliza una forma simple de
-   pseudo-código. El pseudo-código se escribe en inglés para que pueda ser
-   más fácilmente contrastado con la literatura, que está en inglés. Para
-   diferenciar posiciones de memoria y punteros de las celdas en sí, se usa
-   la misma sintaxis que C, ``r*`` denota una referencia o puntero y ``*r``
+   pseudo-código. El pseudo-código se escribe en inglés para que pueda ser más
+   fácilmente contrastado con la literatura, que está en inglés. Para
+   diferenciar posiciones de memoria y punteros de las celdas en sí, se usa la
+   misma sintaxis que C, ``r*`` denota una referencia o puntero y ``*r``
    denota "objeto al que apunta ``r``\ ". Se sobreentiende que ``r = o``
    siempre toma la dirección de memoria de ``o``.
 
-Una vez concluido el marcado, sabemos que todos los vértices con la marca
-son parte del *live set* y que todos los vértices no marcados son *basura*.
-Esto es conocido también como **abstracción bicolor**, dado que en la
-literatura se habla muchas veces de *colorear* las celdas. En general, una
-celda sin marcar es de color blanco y una marcada de color negro.
+Una vez concluido el marcado, sabemos que todos los vértices con la marca son
+parte del *live set* y que todos los vértices no marcados son *basura*.  Esto
+es conocido también como **abstracción bicolor**, dado que en la literatura se
+habla muchas veces de *colorear* las celdas. En general, una celda sin marcar
+es de color blanco y una marcada de color negro.
 
-Puede observarse un ejemplo del algoritmo en la figura
-:vref:`fig:gc-mark-1`, en la cual se marca el sub-grafo apuntando por
-``r0``. Luego se marca el sub-grafo al que apunta ``r1`` (ver figura
-:vref:`fig:gc-mark-2`), concluyendo con el marcado del grafo completo,
-dejando sin marcar solamente las celdas *basura* (en blanco).
+Puede observarse un ejemplo del algoritmo en la figura :vref:`fig:gc-mark-1`,
+en la cual se marca el sub-grafo apuntando por ``r0``. Luego se marca el
+sub-grafo al que apunta ``r1`` (ver figura :vref:`fig:gc-mark-2`), concluyendo
+con el marcado del grafo completo, dejando sin marcar solamente las celdas
+*basura* (en blanco).
 
 
 .. fig:: fig:gc-mark-1
@@ -594,34 +589,34 @@ dejando sin marcar solamente las celdas *basura* (en blanco).
 
 
 
-.. _ref_gc_intro_tricolor:
+.. _gc_intro_tricolor:
 
 Abstracción tricolor
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Muchos algoritmos utilizan tres colores para realizar el marcado. El tercer
-color, gris generalmente, indica que una celda debe ser visitada. Esto
-permite algoritmos :ref:`concurrentes <ref_gc_concurrent>`
-e :ref:`incrementales <ref_gc_inc>`, además de otro tipo de optimizaciones.
-Entonces, lo que plantea esta abtracción es una nueva partición del heap al
-momento de marcar, esta vez son 3 porciones: blanca, gris y negra.
+color, gris generalmente, indica que una celda debe ser visitada. Esto permite
+algoritmos :ref:`concurrentes <gc_concurrent>` e :ref:`incrementales
+<gc_inc>`, además de otro tipo de optimizaciones.  Entonces, lo que plantea
+esta abtracción es una nueva partición del heap al momento de marcar, esta vez
+son 3 porciones: blanca, gris y negra.
 
-Al principio todas las celdas se pintan de blanco, excepto el *root set*
-que se punta de gris. Luego se van obteniendo celdas del conjunto de las
-grises y se las pinta de negro, pintando sus hijas directas de gris.
+Al principio todas las celdas se pintan de blanco, excepto el *root set* que
+se punta de gris. Luego se van obteniendo celdas del conjunto de las grises
+y se las pinta de negro, pintando sus hijas directas de gris.
 
 Una vez que no hay más celdas grises, tenemos la garantía de que las celdas
-negras serán el *live set* y las celdas blancas *basura*. Esto se debe
-a que siempre se mantiene esta invariante: **ninguna celda negra apunta
-directamente a una celda blanca**. Las celdas blancas siempre son apuntadas
-por celdas blancas o grises. Entonces, siempre que el conjunto de celdas
-grises sea vacío, no habrán celdas negras conectadas a blancas, siendo las
-celdas blancas *basura*.
+negras serán el *live set* y las celdas blancas *basura*. Esto se debe a que
+siempre se mantiene esta invariante: **ninguna celda negra apunta directamente
+a una celda blanca**. Las celdas blancas siempre son apuntadas por celdas
+blancas o grises. Entonces, siempre que el conjunto de celdas grises sea
+vacío, no habrán celdas negras conectadas a blancas, siendo las celdas blancas
+*basura*.
 
 El algoritmo básico para marcar con tres colores es el siguiente (asumiendo
-que todas las celdas parten pintadas de blanco, es decir, el conjunto
-blanco contiene todas las celdas de memoria y los conjuntos negro y gris
-están vacíos)::
+que todas las celdas parten pintadas de blanco, es decir, el conjunto blanco
+contiene todas las celdas de memoria y los conjuntos negro y gris están
+vacíos)::
 
    function mark_phase() is
       foreach r in root_set
@@ -634,31 +629,30 @@ están vacíos)::
                white_set.remove(v)
                gray_set.add(v)
 
-Es simple notar que este algoritmo es naturalmente no recursivo, lo que de
-por sí ya presenta una ventaja sobre el marcado *bicolor*.
+Es simple notar que este algoritmo es naturalmente no recursivo, lo que de por
+sí ya presenta una ventaja sobre el marcado *bicolor*.
 
 
 
-.. _ref_gc_intro_services:
+.. _gc_intro_services:
 
 Servicios
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-En general todos los algoritmos de recolección de basura utilizan servicios
-de una capa inferior [#gclowlayer]_ y proveen servicios a una capa superior
+En general todos los algoritmos de recolección de basura utilizan servicios de
+una capa inferior [#gclowlayer]_ y proveen servicios a una capa superior
 [#gchilayer]_.
 
 .. [#gclowlayer] En general estos servicios están provistos directamente
    por el sistema operativo pero también pueden estar dados por un
-   administrador de memoria de bajo nivel (o *low level allocator* en
-   inglés).
+   administrador de memoria de bajo nivel (o *low level allocator* en inglés).
 
 .. [#gchilayer] En general estos servicios son utilizados directamente por
-   el lenguaje de programación, pero pueden ser utilizados directamente por
-   el usuario del lenguaje si éste interatúa con el recolector, ya sea por
-   algún requerimiento particular o porque el lenguaje no tiene soporte
-   diercto de recolección de basura y el recolector está implementado como
-   una biblioteca de usuario.
+   el lenguaje de programación, pero pueden ser utilizados directamente por el
+   usuario del lenguaje si éste interatúa con el recolector, ya sea por algún
+   requerimiento particular o porque el lenguaje no tiene soporte diercto de
+   recolección de basura y el recolector está implementado como una biblioteca
+   de usuario.
 
 A continuación se presentan las primitivas en común que utilizan todos los
 recolectores a lo largo de este documento.
@@ -666,25 +660,23 @@ recolectores a lo largo de este documento.
 Servicios utilizados por el recolector son los siguientes:
 
 :math:`alloc() \to cell`:
-   obtiene una nueva celda de memoria. El mecanismo por el cual se obtiene
-   la celda es indistinto para esta sección, puede ser de una lista libre,
-   puede ser de un administrador de memoria de más bajo nivel provisto por
-   el sistema operativo o la biblioteca estándar de C (``malloc()``), etc.
-   Cómo organizar la memoria es un área de investigación completa y si bien
-   está estrechamente relacionada con la recolección de basura, en este
-   trabajo no se prestará particular atención a este aspecto (salvo casos
-   donde el recolector impone una cierta organización de memoria en el *low
-   level allocator*). Por simplicidad también asumiremos (a menos que se
-   indique lo contrario) que las celdas son de tamaño fijo. Esta restricción
-   normalmente puede ser fácilmente relajada (en los recolectores que la
-   tienen).
+   obtiene una nueva celda de memoria. El mecanismo por el cual se obtiene la
+   celda es indistinto para esta sección, puede ser de una lista libre, puede
+   ser de un administrador de memoria de más bajo nivel provisto por el
+   sistema operativo o la biblioteca estándar de C (``malloc()``), etc.  Cómo
+   organizar la memoria es un área de investigación completa y si bien está
+   estrechamente relacionada con la recolección de basura, en este trabajo no
+   se prestará particular atención a este aspecto (salvo casos donde el
+   recolector impone una cierta organización de memoria en el *low level
+   allocator*). Por simplicidad también asumiremos (a menos que se indique lo
+   contrario) que las celdas son de tamaño fijo. Esta restricción normalmente
+   puede ser fácilmente relajada (en los recolectores que la tienen).
 
 :math:`free(cell)`:
-   libera una celda que ya no va a ser utilizada. La celda liberada debe
-   haber sido obtenida mediante ``alloc()``.
+   libera una celda que ya no va a ser utilizada. La celda liberada debe haber
+   sido obtenida mediante ``alloc()``.
 
-Y los servicios básicos proporcionados por el recolector son los
-siguientes:
+Y los servicios básicos proporcionados por el recolector son los siguientes:
 
 :math:`new() \to cell`:
    obtiene una celda de memoria para ser utilizada por el programa.
@@ -696,62 +688,60 @@ siguientes:
    por :math:`src \to new` (donde :math:`src` es la celda que contiene la
    referencia :math:`ref`, :math:`old` es la celda a la que apunta la
    referencia :math:`ref` y :math:`new` es el argumento :math:`cell`). Si
-   :math:`cell` es ``null``, sería análogo a informar que se elimina la
-   arista :math:`src \to old`.
+   :math:`cell` es ``null``, sería análogo a informar que se elimina la arista
+   :math:`src \to old`.
 
 :math:`del(cell)`:
    este servicio, según el algoritmo, puede ser utilizado para informar un
-   cambio en la conectividad del grafo, la eliminación de una arista
-   (análogo a :math:`update(ref, null)` pero sin proporcionar información
-   sobre la arista a eliminar). Esto es generalmente útil solo en
-   :ref:`conteo de referencias <ref_gc_rc>`. Para otros recolectores puede
-   significar que el usuario asegura que no hay más referencias a esta
-   celda, es decir, análogo a eliminar el conjunto de aristas
-   :math:`\big\lbrace (v, w) \in A , v \in Live \thickspace set , w \in
-   Live \thickspace set \big/ w = cell`.
+   cambio en la conectividad del grafo, la eliminación de una arista (análogo
+   a :math:`update(ref, null)` pero sin proporcionar información sobre la
+   arista a eliminar). Esto es generalmente útil solo en :ref:`conteo de
+   referencias <gc_rc>`. Para otros recolectores puede significar que el
+   usuario asegura que no hay más referencias a esta celda, es decir, análogo
+   a eliminar el conjunto de aristas :math:`\big\lbrace (v, w) \in A , v \in
+   Live \thickspace set , w \in Live \thickspace set \big/ w = cell`.
 
 :math:`collect()`:
    indica al recolector que debe hacer un análisis del grafo de conectividad
-   en busca de *basura*. Generalmente este servicio es invocado por el
-   propio recolector cuando no hay más celdas reciclables.
+   en busca de *basura*. Generalmente este servicio es invocado por el propio
+   recolector cuando no hay más celdas reciclables.
 
-No todos los servicios son implementados por todos los recolectores, pero
-son lo suficientemente comunes como para describirlos de forma general en
-esta sección. Algunos son principalmente ideados para uso interno del
-recolector, aunque en ciertas circunstancias pueden ser utilizados por el
-usuario también.
+No todos los servicios son implementados por todos los recolectores, pero son
+lo suficientemente comunes como para describirlos de forma general en esta
+sección. Algunos son principalmente ideados para uso interno del recolector,
+aunque en ciertas circunstancias pueden ser utilizados por el usuario también.
 
 
 
-.. _ref_gc_classic:
+.. _gc_classic:
 
 Algoritmos clásicos
 ----------------------------------------------------------------------------
 
 En la literatura se encuentran normalmente referencias a 3 algoritmos
-clásicos, que son utilizados generalmente como bloques básicos para
-construir recolectores más complejos. Se presentan las versiones históricas
-más simples a fin de facilitar la comprensión conceptual.
+clásicos, que son utilizados generalmente como bloques básicos para construir
+recolectores más complejos. Se presentan las versiones históricas más simples
+a fin de facilitar la comprensión conceptual.
 
 
 
-.. _ref_gc_rc:
+.. _gc_rc:
 
 Conteo de referencias
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Se trata del algoritmo más antiguo de todos, implementado por primera vez
-por `John McCarthy`_ para Lisp_ a finales de 1950. Se trata de un método
-:ref:`directo <ref_gc_direct>` e :ref:`incremental <ref_gc_inc>` por
-naturaleza, ya que distribuye la carga de la recolección de basura durante
-toda la ejecución del programa, cada vez que el *mutator* cambia la
-conectividad de algún nodo del grafo de conectividad.
+Se trata del algoritmo más antiguo de todos, implementado por primera vez por
+`John McCarthy`_ para Lisp_ a finales de 1950. Se trata de un método
+:ref:`directo <gc_direct>` e :ref:`incremental <gc_inc>` por naturaleza, ya
+que distribuye la carga de la recolección de basura durante toda la ejecución
+del programa, cada vez que el *mutator* cambia la conectividad de algún nodo
+del grafo de conectividad.
 
-El método consiste en tener un contador asociado a cada celda que contenga
-la cantidad de celdas **vivas** que apuntan a ésta. Es decir, es la
-cardinalidad del conjunto de aristas que tienen por destino a la celda.
-Formalmente podemos definir el contador :math:`rc(v)` (de *reference
-counter* en inglés) de la siguiente manera:
+El método consiste en tener un contador asociado a cada celda que contenga la
+cantidad de celdas **vivas** que apuntan a ésta. Es decir, es la cardinalidad
+del conjunto de aristas que tienen por destino a la celda.  Formalmente
+podemos definir el contador :math:`rc(v)` (de *reference counter* en inglés)
+de la siguiente manera:
 
 .. math::
 
@@ -763,35 +753,35 @@ counter* en inglés) de la siguiente manera:
       \right\rbrace
    \big\rvert
 
-El *mutator* entonces debe actualizar este contador cada vez que el grafo
-de conectividad cambia, es decir, cada vez que se agrega, modifica
-o elimina una arista del grafo (o visto de una forma más cercana al código,
-cada vez que se agrega, modifica o elimina un puntero).
+El *mutator* entonces debe actualizar este contador cada vez que el grafo de
+conectividad cambia, es decir, cada vez que se agrega, modifica o elimina una
+arista del grafo (o visto de una forma más cercana al código, cada vez que se
+agrega, modifica o elimina un puntero).
 
-Esta invariante es fundamental para el conteo de referencias, porque se
-asume que si el contador es 0 entonces el *mutator* no tiene ninguna
-referencia a la celda y por lo tanto es *basura*:
+Esta invariante es fundamental para el conteo de referencias, porque se asume
+que si el contador es 0 entonces el *mutator* no tiene ninguna referencia a la
+celda y por lo tanto es *basura*:
 
 .. math::
 
    rc(v) = 0 \Rightarrow v \in Basura
 
 Para mantener esta invariante el *mutator*, cada vez que cambia un puntero
-debe decrementar en 1 el contador de la celda a la que apuntaba
-antiguamente  e incrementar en 1 el contador de la celda a la que apunta
-luego de la modificación. Esto asegura que la invariante se mantenga
-durante toda la ejecución del programa. Si al momento de decrementar un
-contador éste queda en 0, la celda asociada debe liberarse de forma de
-poder ser reciclada. Esto implica que si esta celda almacena punteros, los
-contadores de las celdas apuntadas deben ser decrementados también, porque
-solo deben almacenarse en el contador las aristas del *live set* para
-mantener la invariante. De esto puede resultar que otros contadores de
-referencia queden en 0 y más celdas sean liberadas. Por lo tanto,
-teóricamente la complejidad de eliminar una referencia puede ser
-:math:`O(\lvert Live \thickspace set \rvert)` en el peor caso.
-
-Las primitivas implementadas para este tipo de recolector son las
-siguientes (acompañadas de una implementación básica)::
+debe decrementar en 1 el contador de la celda a la que apuntaba antiguamente
+e incrementar en 1 el contador de la celda a la que apunta luego de la
+modificación. Esto asegura que la invariante se mantenga durante toda la
+ejecución del programa. Si al momento de decrementar un contador éste queda en
+0, la celda asociada debe liberarse de forma de poder ser reciclada. Esto
+implica que si esta celda almacena punteros, los contadores de las celdas
+apuntadas deben ser decrementados también, porque solo deben almacenarse en el
+contador las aristas del *live set* para mantener la invariante. De esto puede
+resultar que otros contadores de referencia queden en 0 y más celdas sean
+liberadas. Por lo tanto, teóricamente la complejidad de eliminar una
+referencia puede ser :math:`O(\lvert Live \thickspace set \rvert)` en el peor
+caso.
+
+Las primitivas implementadas para este tipo de recolector son las siguientes
+(acompañadas de una implementación básica)::
 
    function new() is
       cell = alloc()
@@ -814,42 +804,41 @@ siguientes (acompañadas de una implementación básica)::
 
 
 
-.. _ref_gc_rc_cycles:
+.. _gc_rc_cycles:
 
 Ciclos
 ^^^^^^
 
-El conteo de referencias tiene, sin embargo, un problema fundamental:
-**falla con estructuras cíclicas**. Esto significa que siempre que haya un
-ciclo en el grafo de conectividad, hay una pérdida de memoria potencial en
-el programa. Un ciclo es un camino :math:`\underset{v \to v}{C}`, es decir,
-el *vértice inicial* es el mismo que el *vértice final*.
+El conteo de referencias tiene, sin embargo, un problema fundamental: **falla
+con estructuras cíclicas**. Esto significa que siempre que haya un ciclo en el
+grafo de conectividad, hay una pérdida de memoria potencial en el programa. Un
+ciclo es un camino :math:`\underset{v \to v}{C}`, es decir, el *vértice
+inicial* es el mismo que el *vértice final*.
 
 Cuando esto sucede, las celdas que participan del ciclo tienen siempre su
 contador mayor que 0, sin embargo puede no haber ningún elemento del *root
 set* que apunte a una celda dentro del ciclo, por lo tanto el ciclo es
-*basura* (al igual que cualquier otra celda que sea referenciada por el
-ciclo pero que no tenga otras referencias externas) y sin embargo los
-contadores no son 0. Los ciclos, por lo tanto, *rompen* la invariante del
-conteo de referencia.
+*basura* (al igual que cualquier otra celda que sea referenciada por el ciclo
+pero que no tenga otras referencias externas) y sin embargo los contadores no
+son 0. Los ciclos, por lo tanto, *rompen* la invariante del conteo de
+referencia.
 
 Hay formas de solucionar esto, pero siempre recaen en un esquema que va por
-fuera del conteo de referencias puro. En general los métodos para
-solucionar esto son variados y van desde realizar un marcado del subgrafo
-para detectar nodos hasta tener otro recolector completo de *emergencia*,
-pasando por tratar los ciclos como un todo contar las referencias al ciclo
-completo en vez de a cada celda en particular.
+fuera del conteo de referencias puro. En general los métodos para solucionar
+esto son variados y van desde realizar un marcado del subgrafo para detectar
+nodos hasta tener otro recolector completo de *emergencia*, pasando por tratar
+los ciclos como un todo contar las referencias al ciclo completo en vez de
+a cada celda en particular.
 
-Incluso con este problema, el conteo de referencia sin ningún tipo de
-solución en cuanto a la detección y recolección de ciclos fue utilizado en
-muchos lenguajes de programación sin que su necesidad sea tan evidente. Por
-ejemplo Python_ agregó recolección de ciclos en la versión 2.0 [NAS00]_
-(liberada en octubre de 2000) y PHP_ recién agrega detección de ciclos en
-la versión 5.3 (todavía no liberada al momento de escribir este documento)
-[PHP081]_.
+Incluso con este problema, el conteo de referencia sin ningún tipo de solución
+en cuanto a la detección y recolección de ciclos fue utilizado en muchos
+lenguajes de programación sin que su necesidad sea tan evidente. Por ejemplo
+Python_ agregó recolección de ciclos en la versión 2.0 [NAS00]_ (liberada en
+octubre de 2000) y PHP_ recién agrega detección de ciclos en la versión 5.3
+(todavía no liberada al momento de escribir este documento) [PHP081]_.
 
 
-.. _ref_gc_rc_example:
+.. _gc_rc_example:
 
 Ejemplo
 ^^^^^^^
@@ -860,17 +849,19 @@ punteros, ``left`` (``l``) y ``right`` (``r``) y se muestra el contador de
 referencias abajo del nombre de cada celda. Se parte con una pequeña
 estructura ya construída y se muestra como opera el algoritmo al eliminar
 o cambiar una referencia (cambios en la conectividad del grafo). En un
-comienzo todas las celdas son accesibles desde el *root set* por lo tanto
-son todas parte del *live set*.
+comienzo todas las celdas son accesibles desde el *root set* por lo tanto son
+todas parte del *live set*.
 
-Se comienza por eliminar la referencia de ``r0`` a ``h1``, que determina
-que ``h1`` se convirtió en *basura* (ver figura :vref:`fig:gc-rc-rm-1`). Esto
+Se comienza por eliminar la referencia de ``r0`` a ``h1``, que determina que
+``h1`` se convirtió en *basura* (ver figura :vref:`fig:gc-rc-rm-1`). Esto
 conduce al decremento del contador de ``h2`` y ``h3`` que permanecen en el
 *live set* ya que sus contadores siguen siendo mayores a 0 (ver figura
 :vref:`fig:gc-rc-rm-2`).
 
 .. fig:: fig:gc-rc-rm-1
 
+   Ejemplo de conteo de referencias: eliminación de una referencia (parte 1).
+
    Eliminación de la referencia ``r0`` :math:`\to` ``h1`` (parte 1).
 
    .. subfig::
@@ -970,8 +961,8 @@ conduce al decremento del contador de ``h2`` y ``h3`` que permanecen en el
 
    .. subfig::
 
-      Se decrementa el contador de ``h1`` quedando en 0 (pasa a ser
-      *basura*). Se elimina primero ``h1.l`` y luego ``h1.r``.
+      Se decrementa el contador de ``h1`` quedando en 0 (pasa a ser *basura*).
+      Se elimina primero ``h1.l`` y luego ``h1.r``.
 
       .. digraph:: g3_3
 
@@ -1025,12 +1016,14 @@ conduce al decremento del contador de ``h2`` y ``h3`` que permanecen en el
 .. fig:: fig:gc-rc-rm-2
    :padding: 0.5
 
+   Ejemplo de conteo de referencias: eliminación de una referencia (parte 2).
+
    Eliminación de la referencia ``r0`` :math:`\to` ``h1`` (parte 2).
 
    .. subfig::
 
-      Se decrementa el contador de ``h2`` pero no queda en 0 (permanece en
-      el *live set*).
+      Se decrementa el contador de ``h2`` pero no queda en 0 (permanece en el
+      *live set*).
 
       .. digraph:: g3_4
 
@@ -1134,16 +1127,18 @@ conduce al decremento del contador de ``h2`` y ``h3`` que permanecen en el
 
 
 Luego se cambia una referencia (en vez de eliminarse) realizándose la
-operación ``update(h3.l, h5)``. Para esto primero se incrementa el contador
-de referencias de ``h5`` para evitar confundirlo accidentalmente con
-*basura* si se elimina alguna celda que apuntaba a ésta. Luego se procede
-a decrementar el contador de ``h2`` que queda en 0, transformándose en
-*basura* (ver figura :vref:`fig:gc-rc-up-1`).
+operación ``update(h3.l, h5)``. Para esto primero se incrementa el contador de
+referencias de ``h5`` para evitar confundirlo accidentalmente con *basura* si
+se elimina alguna celda que apuntaba a ésta. Luego se procede a decrementar el
+contador de ``h2`` que queda en 0, transformándose en *basura* (ver figura
+:vref:`fig:gc-rc-up-1`).
 
 .. fig:: fig:gc-rc-up-1
 
-   Cambio en la referencia ``h2.l`` :math:`\to` ``h2`` a ``h2.l``
-   :math:`\to` ``h5`` (parte 1).
+   Ejemplo de conteo de referencias: actualización de una referencia (parte 1).
+
+   Cambio en la referencia ``h2.l`` :math:`\to` ``h2`` a ``h2.l`` :math:`\to`
+   ``h5`` (parte 1).
 
    .. subfig::
 
@@ -1253,8 +1248,8 @@ a decrementar el contador de ``h2`` que queda en 0, transformándose en
 
    .. subfig::
 
-      Se decrementa el contador de ``h2`` y queda en 0 (pasa a ser
-      *basura*). Se eliminan las referencias a las hijas.
+      Se decrementa el contador de ``h2`` y queda en 0 (pasa a ser *basura*).
+      Se eliminan las referencias a las hijas.
 
       .. digraph:: g4_3
 
@@ -1314,13 +1309,15 @@ de actualizar la referencia ``h3.l`` para que apunte a ``h5`` (ver figura
 
 .. fig:: fig:gc-rc-up-2
 
-   Cambio en la referencia ``h2.l`` :math:`\to` ``h2`` a ``h2.l``
-   :math:`\to` ``h5`` (parte 2).
+   Ejemplo de conteo de referencias: actualización de una referencia (parte 2).
+
+   Cambio en la referencia ``h2.l`` :math:`\to` ``h2`` a ``h2.l`` :math:`\to`
+   ``h5`` (parte 2).
 
    .. subfig::
 
-      Se decrementa el contador de ``h4`` quedando en 0, pasa a ser
-      *basura*. Se continúa con ``h5``.
+      Se decrementa el contador de ``h4`` quedando en 0, pasa a ser *basura*.
+      Se continúa con ``h5``.
 
       .. digraph:: g4_4
 
@@ -1482,19 +1479,21 @@ de actualizar la referencia ``h3.l`` para que apunte a ``h5`` (ver figura
 
 Finalmente se presenta lo que sucede cuando se elimina la última referencia
 a un ciclo (en este caso un ciclo simple de 2 celdas: ``h3`` y ``h6``). Se
-elimina la única referencia externa al ciclo (``r1``), por lo que se visita
-la celda ``h3`` decrementando su contador de referencias, pero éste
-continúa siendo mayor que 0 porque la celda ``h6`` (parte del ciclo) la
-referencia. Por lo tanto el ciclo, y todas las celdas a las que apunta que
-no tienen otras referencias externas y por lo tanto deberían ser *basura*
-también (``h5``), no pueden ser recicladas y su memoria es perdida (ver
-figura :vref:`fig:gc-rc-cycle`).
+elimina la única referencia externa al ciclo (``r1``), por lo que se visita la
+celda ``h3`` decrementando su contador de referencias, pero éste continúa
+siendo mayor que 0 porque la celda ``h6`` (parte del ciclo) la referencia. Por
+lo tanto el ciclo, y todas las celdas a las que apunta que no tienen otras
+referencias externas y por lo tanto deberían ser *basura* también (``h5``), no
+pueden ser recicladas y su memoria es perdida (ver figura
+:vref:`fig:gc-rc-cycle`).
 
 .. fig:: fig:gc-rc-cycle
    :padding: 0.5
 
-   Eliminación de la referencia ``r1`` :math:`\to` ``h3`` (pérdida de
-   memoria debido a un ciclo).
+   Ejemplo de conteo de referencias: pérdida de memoria debido a un ciclo.
+
+   Eliminación de la referencia ``r1`` :math:`\to` ``h3`` (pérdida de memoria
+   debido a un ciclo).
 
    .. subfig::
 
@@ -1552,8 +1551,8 @@ figura :vref:`fig:gc-rc-cycle`).
 
    .. subfig::
 
-      Se decrementa el contador de ``h3`` pero sigue siendo mayor que 0 por
-      el ciclo.
+      Se decrementa el contador de ``h3`` pero sigue siendo mayor que 0 por el
+      ciclo.
 
       .. digraph:: g5_2
 
@@ -1607,7 +1606,7 @@ figura :vref:`fig:gc-rc-cycle`).
 
 
 
-.. _ref_gc_mark_sweep:
+.. _gc_mark_sweep:
 
 Marcado y barrido
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -1616,7 +1615,7 @@ Este algoritmo es el más parecido a la teoría sobre recolección de basura.
 Consiste en realizar la recolección en 2 fases: marcado y barrido. La primera
 fase consiste en el proceso de marcar el grafo de conectividad del *heap* para
 descubrir qué celdas son alcanzables desde el *root set*, tal y como se
-describió en :ref:`ref_gc_intro_mark`.
+describió en :ref:`gc_intro_mark`.
 
 Una vez marcadas todas las celdas, se sabe que las celdas *blancas* son
 *basura*, por lo tanto el paso que queda es el *barrido* de estas celdas,
@@ -1652,44 +1651,52 @@ A continuación se presentan los servicios básicos de este algoritmo::
             free(cell)
 
 El algoritmo ``mark_sweep()`` es exactamente igual al presentado en
-:ref:`ref_gc_intro_mark`. Es preciso notar que la fase de barrido
+:ref:`gc_intro_mark`. Es preciso notar que la fase de barrido
 (``sweep_phase()``) debe tener una comunicación extra con el *low level
 allocator* para poder obtener todas las celdas de memoria que existen en el
 *heap*.
 
 A diferencia del conteo de referencias, este algoritmo es :ref:`indirecto
-<ref_gc_direct>` y :ref:`no incremental <ref_gc_inc>`, ya que se realiza un
-recorrido de todo el *heap* de forma espaciada a través de la ejecución del
-programa. En general el *mutator* sufre pausas considerablemente mayores (en
-promedio) que con el conteo de referencias, lo que puede ser problemático para
-aplicaciones con requerimientos rígidos de tiempo, como aplicaciones
-*real-time*. Debido a la percepción de las pausas grandes, este tipo de
-colectores se conocen como :ref:`stop-the-world <ref_gc_concurrent>` (o
-*detener el mundo*).
+<gc_direct>` y :ref:`no incremental <gc_inc>`, ya que se realiza un recorrido
+de todo el *heap* de forma espaciada a través de la ejecución del programa. En
+general el *mutator* sufre pausas considerablemente mayores (en promedio) que
+con el conteo de referencias, lo que puede ser problemático para aplicaciones
+con requerimientos rígidos de tiempo, como aplicaciones *real-time*. Debido
+a la percepción de las pausas grandes, este tipo de colectores se conocen como
+:ref:`stop-the-world <gc_concurrent>` (o *detener el mundo*).
 
 Una ventaja fundamental sobre el conteo de referencias es la posibilidad de
 reclamar estructuras cíclicas sin consideraciones especiales. Podemos observar
-como esto es posible analizando el ejemplo en las figuras
-:r:`fig:gc-mark-1` y :vref:`fig:gc-mark-2`. Si se eliminaran las referencias
-:math:`r0 \to h1` y :math:`h6 \to h2`, la fase de marcado consistiría
-solamente en marcar la celda :math:`h6`, pues es la única alcanzable desde el
-*root set*. Todas las demás celdas permanecerían blancas y por lo tanto pueden
-ser liberadas sin inconvenientes en la fase de barrido, que recorre el *heap*
-linealmente.
+como esto es posible analizando el ejemplo en las figuras :r:`fig:gc-mark-1`
+y :vref:`fig:gc-mark-2`. Si se eliminaran las referencias :math:`r0 \to h1`
+y :math:`h6 \to h2`, la fase de marcado consistiría solamente en marcar la
+celda :math:`h6`, pues es la única alcanzable desde el *root set*. Todas las
+demás celdas permanecerían blancas y por lo tanto pueden ser liberadas sin
+inconvenientes en la fase de barrido, que recorre el *heap* linealmente.
 
 
 
-.. _ref_gc_copy:
+.. _gc_copy:
 
 Copia de semi-espacio
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Este algoritmo consiste en hacer una partición del *heap* en 2 mitades
 o *semi-espacios*, llamados usualmente *Fromspace* y *Tospace*. El primero se
-utiliza para alocar nuevas celdas de forma lineal, asumiendo un *heap*
+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 alocar memoria (tan eficiente como alocar memoria en el *stack*).
+eficiente de asignar memoria (tan eficiente como asignar memoria en el
+*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
 
@@ -1698,7 +1705,6 @@ eficiente de alocar memoria (tan eficiente como alocar memoria en el *stack*).
    .. aafig::
       :aspect: 0.7
       :scale: 1.4
-      :proportional:
 
       zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz
 
@@ -1723,13 +1729,13 @@ La segunda mitad (*Tospace*) permanece inutilizada hasta que se agota el
 espacio en el *Fromspace*; en ese momento comienza el proceso de recolección
 de basura que consiste en recorrer el grafo de conectividad, copiando las
 celdas *vivas* del *Fromspace* al *Tospace* de manera contigua, como si
-estuvieran alocando por primera vez. Como la posición en memoria de las celdas
-cambia al ser movidas, es necesario actualizar la dirección de memoria de
-todas las celdas *vivas*. Para esto se almacena una dirección de memoria de
+estuvieran asignando por primera vez. Como la posición en memoria de las
+celdas cambia al ser movidas, es necesario actualizar la dirección de memoria
+de todas las celdas *vivas*. Para esto se almacena una dirección de memoria de
 redirección, *forwarding address*, en las celdas que mueven. La *forwarding
 address* sirve a su vez de marca, para no recorrer una celda dos veces (como
-se explica en :ref:`ref_gc_intro_mark`). Cuando se encuentra una celda que ya
-fue movida, simplemente se actualiza la referencia por la cual se llegó a esa
+se explica en :ref:`gc_intro_mark`). Cuando se encuentra una celda que ya fue
+movida, simplemente se actualiza la referencia por la cual se llegó a esa
 celda para que apunte a la nueva dirección, almacenada en la *forwarding
 address*. Una vez finalizado este proceso, el *Fromspace* y *Tospace*
 invierten roles y se prosigue de la misma manera (todo lo que quedó en el
@@ -1739,16 +1745,16 @@ viejo *Fromspace* es *basura* por definición, por lo que se convierte el
 A continuación se presenta una implementación sencilla de los servicios
 provistos por este tipo de recolectores. Cabe destacar que este tipo de
 recolectores deben estar íntimamente relacionados con el *low level
-allocator*, ya que la organización del *heap* y la forma de alocar
-memoria es parte fundamental de este algoritmo. Se asume que ya hay dos áreas
-de memoria del mismo tamaño destinadas al *Fromspace* y *Tospace*, y la
-existencia de 4 variables: ``fromspace`` (que apunta a la base del
-*Fromspace*), ``tospace`` (que apunta a la base del *Tospace*), ``spacesize``
-(que contiene el tamaño de un semi-espacio) y ``free`` (que apunta al lugar
-del *Fromspace* donde comienza la memoria libre). También vale aclarar que
-este algoritmo soporta inherentemente celdas de tamaño variable, por lo que
-los servicios ``alloc()`` y ``new()`` [#gccopynew]_ reciben como parámetro el
-tamaño de la celda a alocar::
+allocator*, ya que la organización del *heap* y la forma de asignar memoria es
+parte fundamental de este algoritmo. Se asume que ya hay dos áreas de memoria
+del mismo tamaño destinadas al *Fromspace* y *Tospace*, y la existencia de
+4 variables: ``fromspace`` (que apunta a la base del *Fromspace*), ``tospace``
+(que apunta a la base del *Tospace*), ``spacesize`` (que contiene el tamaño de
+un semi-espacio) y ``free`` (que apunta al lugar del *Fromspace* donde
+comienza la memoria libre). También vale aclarar que este algoritmo soporta
+inherentemente celdas de tamaño variable, por lo que los servicios ``alloc()``
+y ``new()`` [#gccopynew]_ reciben como parámetro el tamaño de la celda
+a asignar::
 
    function alloc(size) is
       if free + size > fromspace + spacesize
@@ -1790,11 +1796,11 @@ Esta técnica tiene nombres variados en inglés: *semi-space*, *two-space*
 o simplemente *copying collector*. En este documento se denomina "copia de
 semi-espacio" porque los otros nombres son demasiado generales y pueden
 describir, por ejemplo, algoritmos donde no hay copia de celdas o donde no hay
-2 semi-espacios (como se verá en :ref:`ref_gc_art`).
+2 semi-espacios (como se verá en :ref:`gc_art`).
 
-Al igual que el :ref:`ref_gc_mark_sweep` este algoritmo es :ref:`indirecto
-<ref_gc_direct>`, :ref:`no incremental <ref_gc_inc>` y :ref:`stop-the-world
-<ref_gc_concurrent>`. Las diferencias con los esquemas vistos hasta ahora son
+Al igual que el :ref:`gc_mark_sweep` este algoritmo es :ref:`indirecto
+<gc_direct>`, :ref:`no incremental <gc_inc>` y :ref:`stop-the-world
+<gc_concurrent>`. Las diferencias con los esquemas vistos hasta ahora son
 evidentes. La principal ventaja sobre el marcado y barrido (que requiere una
 pasada sobre el *live set*, el marcado, y otra sobre el *heap* entero, el
 barrido) es que este método require una sola pasada y sobre las celdas vivas
@@ -1810,8 +1816,8 @@ de una recolección. En estos casos el trabajo realizado por este tipo de
 recolectores puede ser considerablemente menor que el del marcado y barrido.
 Y por el contrario, si el *working set* es pequeño, al ser *compactado* en
 memoria puede mejorar la localidad de referencia (si el *working set* es
-grande se corre el riesgo de que la localidad de referencia empeore al
-moverse las celdas).
+grande se corre el riesgo de que la localidad de referencia empeore al moverse
+las celdas).
 
 
 Ejemplo
@@ -1836,9 +1842,7 @@ apunta a ``h3``, por lo tanto ésta es movida al *Tospace* primero, dejando una
       la recolección.
 
       .. aafig::
-         :aspect: 0.5
          :scale: 1.25
-         :proportional:
 
          +--------------------------------------------------+
          | "Fromspace"                                      |
@@ -1870,9 +1874,7 @@ apunta a ``h3``, por lo tanto ésta es movida al *Tospace* primero, dejando una
       y dejando una *forwarding address*.
 
       .. aafig::
-         :aspect: 0.5
          :scale: 1.25
-         :proportional:
 
          +--------------------------------------------------+
          | "Fromspace"                                      |
@@ -1919,9 +1921,7 @@ ubicación de ``h2`` pero no se vuelve a copiar la celda (ver figura
       *forwarding address*.
 
       .. aafig::
-         :aspect: 0.5
          :scale: 1.25
-         :proportional:
 
          +--------------------------------------------------+
          | "Fromspace"                                      |
@@ -1954,9 +1954,7 @@ ubicación de ``h2`` pero no se vuelve a copiar la celda (ver figura
       *forwarding address*.
 
       .. aafig::
-         :aspect: 0.5
          :scale: 1.25
-         :proportional:
 
          +--------------------------------------------------+
          | "Fromspace"                                      |
@@ -1999,9 +1997,7 @@ nueva ubicación de ``h3``, como se muestra en la figura
       *forwarding address*.
 
       .. aafig::
-         :aspect: 0.5
          :scale: 1.25
-         :proportional:
 
          +--------------------------------------------------+
          | "Fromspace"                                      |
@@ -2033,9 +2029,7 @@ nueva ubicación de ``h3``, como se muestra en la figura
       semi-espacios y se actualiza la referencia del *root set*.
 
       .. aafig::
-         :aspect: 0.5
          :scale: 1.25
-         :proportional:
 
          +--------------------------------------------------+
          | "Tospace"                                        |
@@ -2063,7 +2057,7 @@ nueva ubicación de ``h3``, como se muestra en la figura
 
 
 
-.. _ref_gc_art:
+.. _gc_art:
 
 Estado del arte
 ----------------------------------------------------------------------------
@@ -2106,7 +2100,7 @@ clase en particular).
 
 
 
-.. _ref_gc_direct:
+.. _gc_direct:
 
 Recolección directa / indirecta
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -2116,81 +2110,79 @@ compilador o lenguaje instrumenta al *mutator* de forma tal que la información
 sobre el grafo de conectividad se mantenga activamente cada vez que hay un
 cambio en él. Normalmente se utiliza un contador de referencia en cada celda
 para este propósito, permitiendo almacenar en todo momento la cantidad de
-nodos que apuntan a ésta (ver :ref:`ref_gc_rc`). Esto permite reclamar una
-celda instantáneamente cuando el *mutator* deja de hacer referencia a ella.
-Este tipo de recolectores son inherentemente :ref:`incrementales
-<ref_gc_inc>`.
-
-Por el contrario, los recolectores **indirectos** normalmente no
-interfieren con el *mutator* en cada actualización del grafo de
-conectividad (exceptuando algunos :ref:`recolectores incrementales
-<ref_gc_inc>` que a veces necesitan instrumentar el *mutator* pero no para
-mantener el estado del grafo de conectividad completo). La recolección se
-dispara usualmente cuando el *mutator* requiere alocar memoria pero no hay
-más memoria libre conocida disponible y el recolector se encarga de generar
-la información de conectividad desde cero para determinar qué celdas son
-*basura*.
+nodos que apuntan a ésta (ver :ref:`gc_rc`). Esto permite reclamar una celda
+instantáneamente cuando el *mutator* deja de hacer referencia a ella.  Este
+tipo de recolectores son inherentemente :ref:`incrementales <gc_inc>`.
+
+Por el contrario, los recolectores **indirectos** normalmente no interfieren
+con el *mutator* en cada actualización del grafo de conectividad (exceptuando
+algunos :ref:`recolectores incrementales <gc_inc>` que a veces necesitan
+instrumentar el *mutator* pero no para mantener el estado del grafo de
+conectividad completo). La recolección se dispara usualmente cuando el
+*mutator* requiere asignar memoria pero no hay más memoria libre conocida
+disponible y el recolector se encarga de generar la información de
+conectividad desde cero para determinar qué celdas son *basura*.
 
 Esta es la madre de toda clasificación, también conocidos como :ref:`conteo de
-referencias <ref_gc_rc>` (directa) y *traicing garbage collection*
-(indirecta). Prácticamente todos los recolectores menos el :ref:`conteo de
-referencias <ref_gc_rc>` están dentro de esta última categoría (como por
-ejemplo, el :ref:`marcado y barrido <ref_gc_mark_sweep>` y :ref:`copia de
-semi-espacio <ref_gc_copy>`).
+referencias <gc_rc>` (directa) y *traicing garbage collection* (indirecta).
+Prácticamente todos los recolectores menos el :ref:`conteo de referencias
+<gc_rc>` están dentro de esta última categoría (como por ejemplo, el
+:ref:`marcado y barrido <gc_mark_sweep>` y :ref:`copia de semi-espacio
+<gc_copy>`).
 
-Otros ejemplos de recolectores modernos *directos* son el recolector de
-basura de Python_ [NAS00]_ y [LINS05]_ (aunque ambos tiene un algoritmo
-*indirecto* para recuperar ciclos).
+Otros ejemplos de recolectores modernos *directos* son el recolector de basura
+de Python_ [NAS00]_ y [LINS05]_ (aunque ambos tiene un algoritmo *indirecto*
+para recuperar ciclos).
 
 
 
-.. _ref_gc_inc:
+.. _gc_inc:
 
 Recolección incremental
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Recolección incremental es aquella que se realiza de forma intercalada con
-el *mutator*. En general el propósito es disminuir el tiempo de las pausas
-causadas por el recolector (aunque generalmente el resultado es un mayor
-costo total de recolección en términos de tiempo).
+Recolección incremental es aquella que se realiza de forma intercalada con el
+*mutator*. En general el propósito es disminuir el tiempo de las pausas
+causadas por el recolector (aunque generalmente el resultado es un mayor costo
+total de recolección en términos de tiempo).
 
 De los `algoritmos clásicos`_ el único que es incremental en su forma más
-básica es el :ref:`conteo de referencias <ref_gc_rc>`. Otros recolectores
-pueden hacerse incrementales de diversas maneras, pero en general consta de
-hacer parte del trabajo de escanear el grafo de conectividad cada vez que el
-*mutator* aloca memoria. En general para hacer esto es también necesario
+básica es el :ref:`conteo de referencias <gc_rc>`. Otros recolectores pueden
+hacerse incrementales de diversas maneras, pero en general consta de hacer
+parte del trabajo de escanear el grafo de conectividad cada vez que el
+*mutator* asigna memoria. En general para hacer esto es también necesario
 instrumentar al *mutator* de forma tal que informe al recolector cada vez que
 cambia el grafo de conectividad, para que éste pueda marcar al sub-grafo
 afectado por el cambio como *desactualizado* y así re-escanearlo nuevamente en
 la próxima iteración. Para realizar esto en recolectores :ref:`indirectos
-<ref_gc_direct>` se utiliza la :ref:`abstracción tricolor
-<ref_gc_intro_tricolor>`; cuando el *mutator* cambia una referencia, se marca
-*gris* la celda que la contiene, de modo que el recolector vuelva a visitarla.
+<gc_direct>` se utiliza la :ref:`abstracción tricolor <gc_intro_tricolor>`;
+cuando el *mutator* cambia una referencia, se marca *gris* la celda que la
+contiene, de modo que el recolector vuelva a visitarla.
 
 En general la eficiencia de los recolectores incrementales disminuye
 considerablemente cuando el *mutator* actualiza muy seguido el grafo de
 conectividad, porque debe re-escanear sub-grafos que ya había escaneado una
-y otra vez. A esto se debe también que en general el tiempo de
-procesamiento total de un recolector incremental sea mayor que uno no
-incremental, aunque el tiempo de pausa de una recolección sea menor.
+y otra vez. A esto se debe también que en general el tiempo de procesamiento
+total de un recolector incremental sea mayor que uno no incremental, aunque el
+tiempo de pausa de una recolección sea menor.
 
 Ejemplos de recolectores que se encuentran dentro de esta categoría son
 [BOEH91]_, [LINS05]_,
 
 
 
-.. _ref_gc_concurrent:
+.. _gc_concurrent:
 
 Recolección concurrente / paralela / *stop-the-world*
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Los recolectores concurrentes son aquellos que pueden correr en paralelo
-con el *mutator*. Por el contrario, aquellos que pausan el *mutator* para
-realizar la recolección son usualmente denominados *stop-the-world* (*detener
-el mundo*), haciendo referencia a que pausan todos los hilos del *mutator*
-para poder escanear el grafo de conectividad de forma consistente. Hay una
-tercera clase de colectores que si bien son *stop-the-world*, utilizan todos
-los hilos disponibles para realizar la recolección (ver figura
+Los recolectores concurrentes son aquellos que pueden correr en paralelo con
+el *mutator*. Por el contrario, aquellos que pausan el *mutator* para realizar
+la recolección son usualmente denominados *stop-the-world* (*detener el
+mundo*), haciendo referencia a que pausan todos los hilos del *mutator* para
+poder escanear el grafo de conectividad de forma consistente. Hay una tercera
+clase de colectores que si bien son *stop-the-world*, utilizan todos los hilos
+disponibles para realizar la recolección (ver figura
 :vref:`fig:gc-concurrent`).
 
 .. fig:: fig:gc-concurrent
@@ -2204,8 +2196,6 @@ los hilos disponibles para realizar la recolección (ver figura
 
       .. aafig::
          :aspect: 0.7
-         :scale: 1.3
-         :proportional:
 
           ___________________________________________________________________
          |                                                                   |
@@ -2224,8 +2214,6 @@ los hilos disponibles para realizar la recolección (ver figura
 
       .. aafig::
          :aspect: 0.7
-         :scale: 1.3
-         :proportional:
 
           ___________________________________________________________________
          |                                                                   |
@@ -2244,8 +2232,6 @@ los hilos disponibles para realizar la recolección (ver figura
 
       .. aafig::
          :aspect: 0.7
-         :scale: 1.3
-         :proportional:
 
           ___________________________________________________________________
          |                                                                   |
@@ -2260,14 +2246,14 @@ los hilos disponibles para realizar la recolección (ver figura
 
 
 Para lograr que un recolector sea concurrente generalmente el mecanismo es
-similar al necesario para hacer un :ref:`recolector incremental
-<ref_gc_inc>`: hay que instrumentar al *mutator* para que informe al
-recolector cuando se realiza algún cambio en el grafo de conectividad, de
-forma tal que pueda volver a escanear el sub-grafo afectado por el cambio.
+similar al necesario para hacer un :ref:`recolector incremental <gc_inc>`: hay
+que instrumentar al *mutator* para que informe al recolector cuando se realiza
+algún cambio en el grafo de conectividad, de forma tal que pueda volver
+a escanear el sub-grafo afectado por el cambio.
 
 Esto también trae como consecuencia el incremento en el tiempo total que
-consume el recolector, debido a la necesidad de re-escanear sub-grafos que
-han sido modificados, además de la sincronización necesaria entre *mutator*
+consume el recolector, debido a la necesidad de re-escanear sub-grafos que han
+sido modificados, además de la sincronización necesaria entre *mutator*
 y recolector.
 
 ¿Cúal es la idea entonces de un recolector concurrente? Una vez más, al igual
@@ -2286,12 +2272,12 @@ ofrece paralelización del procesamiento del recolector en varios hilos) son
    o más núcleos (*cores*) independientes que trabajan a la misma frecuencia,
    pero dentro de un solo circuito integrado o procesador.
 
-Todos los :ref:`algoritmos clásicos <ref_gc_classic>` que se han citado son
-del tipo *stop-the-world*.
+Todos los :ref:`algoritmos clásicos <gc_classic>` que se han citado son del
+tipo *stop-the-world*.
 
 
 
-.. _ref_gc_free_list:
+.. _gc_free_list:
 
 Lista de libres / *pointer bump allocation*
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -2304,70 +2290,69 @@ completamente.
 
 En términos generales, hay dos formas fundamentales de organizar el *heap*,
 manteniendo una lista de libres o realizando *pointer bump allocation*, como
-se explicó en :ref:`ref_gc_copy`. La primera forma consiste, a grandes rasgos,
-en separar el *heap* en celdas (que pueden agruparse según tamaño)
-y enlazarlas en una lista de libres. Al solicitarse una nueva celda
-simplemente se la desenlaza de la lista de libres. Por otro lado, cuando el
-recolector detecta una celda *muerta*, la vuelve a enlazar en la lista de
-libres. Este es un esquema simple pero con limitaciones, entre las
-principales, el costo de alocar puede ser alto si hay muchos tamaños distintos
-de celda y soportar tamaño de celda variable puede ser complejo o acarrear
-muchas otras ineficiencias. :ref:`ref_gc_mark_sweep` en general usa este
-esquema, al igual que :ref:`ref_gc_rc`.
+se explicó en :ref:`gc_copy`. La primera forma consiste, a grandes rasgos, en
+separar el *heap* en celdas (que pueden agruparse según tamaño) y enlazarlas
+en una lista de libres. Al solicitarse una nueva celda simplemente se la
+desenlaza de la lista de libres. Por otro lado, cuando el recolector detecta
+una celda *muerta*, la vuelve a enlazar en la lista de libres. Este es un
+esquema simple pero con limitaciones, entre las principales, el costo de
+asignar puede ser alto si hay muchos tamaños distintos de celda y soportar
+tamaño de celda variable puede ser complejo o acarrear muchas otras
+ineficiencias. :ref:`gc_mark_sweep` en general usa este esquema, al igual que
+:ref:`gc_rc`.
 
 Otro forma de organizar el *heap* es utilizándolo como una especie de *stack*
-en el cual para alocar simplemente se incrementa un puntero. Este esquema es
+en el cual para asignar simplemente se incrementa un puntero. Este esquema es
 simple y eficiente, si el recolector puede mover celdas (ver
-:ref:`ref_gc_moving`); de otra manera alocar puede ser muy costoso si hay que
+:ref:`gc_moving`); de otra manera asignar puede ser muy costoso si hay que
 buscar un *hueco* en el heap (es decir, deja de reducirse a incrementar un
-puntero). El clásico ejemplo de esta familia es :ref:`ref_gc_copy`.
+puntero). El clásico ejemplo de esta familia es :ref:`gc_copy`.
 
 Sin embargo, entre estos dos extremos, hay todo tipo de híbridos. Existen
 recolectores basados en *regiones*, que se encuentran en un punto intermedio.
 Dentro de una región se utiliza un esquema de *pointer bump allocation* pero
 las regiones en sí se administran como una lista de libres (como por ejemplo
 [BLAC08]_). Otra variación (más común) de este esquema son los *two level
-allocators* que alocan páginas completas (similar a las regiones) y dentro de
-cada página se alocan las celdas. Ambas, páginas y celdas, se administran como
-listas de libres (ejemplos que utilizan este esquema son [BOEHWD]_ y el
-:ref:`recolector actual de D <ref_dgc_actual>`).
+allocators* que asignan páginas completas (similar a las regiones) y dentro de
+cada página se asignan las celdas. Ambas, páginas y celdas, se administran
+como listas de libres (ejemplos que utilizan este esquema son [BOEHWD]_ y el
+:ref:`recolector actual de D <dgc_actual>`).
 
 
 
-.. _ref_gc_moving:
+.. _gc_moving:
 
 Movimiento de celdas
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Otra característica muy importante del recolector de basura es si mueve las
 celdas o no. En general el movimiento de celdas viene de la mano del esquema
-de :ref:`pointer bump allocation <ref_gc_free_list>`, ya que *compacta* todas
-las celdas *vivas* al comienzo del *heap* luego de una recolección,
-permitiendo este esquema para alocar nuevas celdas, pero puede utilizarse en
-esquemas híbridos como recolectores basados en *regiones* (por ejemplo
-[BLAC08]_).
+de :ref:`pointer bump allocation <gc_free_list>`, ya que *compacta* todas las
+celdas *vivas* al comienzo del *heap* luego de una recolección, permitiendo
+este esquema para asignar nuevas celdas, pero puede utilizarse en esquemas
+híbridos como recolectores basados en *regiones* (por ejemplo [BLAC08]_).
 
 Además los recolectores con movimiento de celdas deben ser :ref:`precisos
-<ref_gc_conserv>`, porque es necesario tener la información completa de los
-tipos para saber cuando actualizar los punteros (de otra manera se podría
-escribir un dato de una celda que no era un puntero). Para que un recolector
-pueda mover celdas, aunque sea parcialmente, en recolectores *semi-precisos*
-se utiliza un método conocido como *pinning* (que significa algo como *pinchar
+<gc_conserv>`, porque es necesario tener la información completa de los tipos
+para saber cuando actualizar los punteros (de otra manera se podría escribir
+un dato de una celda que no era un puntero). Para que un recolector pueda
+mover celdas, aunque sea parcialmente, en recolectores *semi-precisos* se
+utiliza un método conocido como *pinning* (que significa algo como *pinchar
 con un alfiler*); una celda es *pinned* (*pinchada*) cuando hay alguna
 referencia no-precisa a ella, y por lo tanto no puede ser movida (porque no se
 puede estar seguro si es posible actualizar dicha referencia).
 
 La ventaja principal de los colectores con movimiento es la posibilidad de
-utilizar :ref:`pointer bump allocation <ref_gc_free_list>` y que es sencillo
-implementar recolectores :ref:`generacionales <ref_gc_part>` sobre estos.
+utilizar :ref:`pointer bump allocation <gc_free_list>` y que es sencillo
+implementar recolectores :ref:`generacionales <gc_part>` sobre estos.
 
-De los algoritmos clásicos sólo la :ref:`copia de semi-espacios <ref_gc_copy>`
-mueve celdas, el :ref:`conteo de referencias <ref_gc_rc>` y :ref:`marcado
-y barrido <ref_gc_mark_sweep>` no lo hacen. Además hay otro algoritmo bastante
+De los algoritmos clásicos sólo la :ref:`copia de semi-espacios <gc_copy>`
+mueve celdas, el :ref:`conteo de referencias <gc_rc>` y :ref:`marcado
+y barrido <gc_mark_sweep>` no lo hacen. Además hay otro algoritmo bastante
 básico que mueve celdas, el **marcado y compactado**. Éste no tiene
 2 semi-espacios, directamente mueve las celdas compactándolas al comienzo del
 *heap*. El algoritmo es un poco más complejo que la :ref:`copia de
-semi-espacios <ref_gc_copy>` pero suele poder proveer una mayor localidad de
+semi-espacios <gc_copy>` pero suele poder proveer una mayor localidad de
 referencia y *desperdicia* un semi-espacio que está inutilizado salgo en el
 momento de la recolección. Por ejemplo para Mono_, que antes usaba un
 recolector conservativo sin movimiento ([BOEHWD]_) se está implementando un
@@ -2375,7 +2360,7 @@ recolector de este tipo [MOLAWE]_ [MOLA06]_.
 
 
 
-.. _ref_gc_conserv:
+.. _gc_conserv:
 
 Recolectores conservativos vs precisos
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -2388,8 +2373,8 @@ o no. Esto trae una variada cantidad de problemas, como retención de celdas
 que en realidad son *basura* simplemente porque hay algún dato que coincide
 con la dirección de memoria en la que está almacenada esa celda *basura*
 [#gcflasepos]_. Además los recolectores puramente conservativos no puede mover
-celdas (ver :ref:`ref_gc_moving`), porque no pueden arriesgarse a actualizar
-los punteros por el riesgo que existe de que sean falsos positivos.
+celdas (ver :ref:`gc_moving`), porque no pueden arriesgarse a actualizar los
+punteros por el riesgo que existe de que sean falsos positivos.
 
 .. [#gcflasepos] Esto es lo que se conoce como un *falso positivo*, algo que
    aparenta ser un puntero pero en realidad no lo es.
@@ -2414,21 +2399,20 @@ de forma conservativa y otras de forma precisa, de manera de mitigar, aunque
 sea de forma parcial, los efectos adversos de los recolectores conservativos.
 Estos recolectores son conocidos como *semi-precisos*. Los recolectores
 semi-precisos pueden mover celdas si utilizan un mecanismo de *pinning* (ver
-:ref:`ref_gc_moving`).
+:ref:`gc_moving`).
 
 El ejemplo de recolector conservativo por excelencia es el recolector
 `Boehm-Demers-Wiser`_ ([BOEH88]_, [BOEH91]_, [BOEH93]_, [BOEHWD]_) aunque
 puede comportarse de forma semi-precisa si el usuario se encarga de darle la
 información de tipos (en cuyo caso el recolector deja de ser transparente para
 el usuario). Otros ejemplos de recolectores con cierto grado de
-conservativismo son el :ref:`recolector actual de D <ref_dgc_actual>`
-y [BLAC08]_.
+conservativismo son el :ref:`recolector actual de D <dgc_actual>` y [BLAC08]_.
 
 
 
-.. _ref_gc_part:
+.. _gc_part:
 
-Recolección particionada
+Recolección particionada / generacional
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Otra forma de reducir la cantidad de pausas y la cantidad de trabajo realizado
@@ -2445,8 +2429,6 @@ donde el trabajo va a ser mejor recompensado (ver :vref:`fig:gc-part`).
 
    .. aafig::
       :aspect: 0.7
-      :scale: 1.3
-      :proportional:
 
        _______________________________________________________________________
       |                                                                       |