]> git.llucax.com Git - z.facultad/75.00/informe.git/blobdiff - source/gc.rst
Mencionar ionice(1) en la metodología de pruebas
[z.facultad/75.00/informe.git] / source / gc.rst
index 06ed07e9c1332a3b18c76d03ca743ba6dd41b382..66c64bdbc9efaf360630d7776e8b63f044000445 100644 (file)
@@ -1,10 +1,4 @@
 
 
-.. Introducción a la importancia de la recolección de basura y sus
-   principales técnicas, con sus ventajas y desventajas. También se da
-   un breve recorrido sobre el estado del arte.
-   ESTADO: TERMINADO, CORREGIDO
-
-
 .. _gc:
 
 Recolección de basura
 .. _gc:
 
 Recolección de basura
@@ -156,37 +150,20 @@ 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*.
 
 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:
-
-.. math::
-
-   M \to N \Longleftrightarrow M \text{ almacena un puntero a } N
-
-El conjunto de celdas vivas (o *live set*) queda determinado por:
-
-.. math::
-
-   vivas = \left\lbrace N \in Celdas \big/
-      ( \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
 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
+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 diferencia entre dos partes
 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 diferencia entre dos 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*.
+del programa, el recolector de basura y el programa en sí. A la primera se la
+suele denominar simplemente *recolector* y a la segunda *mutator*, dado que es
+la única que modifica (o *muta*) el grafo de conectividad.
 
 
 
 
 
 
@@ -213,10 +190,11 @@ fueron visitados componen el *live set*; el resto de los vértices son
 Más formalmente, Definimos:
 
 *Camino*
 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*.
+   Es una 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::
 
 
    .. math::
 
@@ -225,8 +203,13 @@ Más formalmente, Definimos:
             \exists (v_i \to v_{i+1}) \in A
       \right\rbrace
 
             \exists (v_i \to v_{i+1}) \in A
       \right\rbrace
 
+   Un camino cuyos *vértices terminales* coinciden, es decir :math:`v_1
+   = v_N`, es denominado **Ciclo**. Cabe notar que los *vértices terminales*
+   de un ciclo son completamente arbitrarios, ya que cualquier *vértice
+   interior* puede ser un *vértice terminal*.
+
 *Conexión*
 *Conexión*
-   decimos que :math:`M` está *conectado* a :math:`N` si y sólo si existe un
+   Decimos que :math:`M` está *conectado* a :math:`N` si y sólo si existe un
    camino de :math:`M` a :math:`N`.
 
    .. math::
    camino de :math:`M` a :math:`N`.
 
    .. math::
@@ -234,9 +217,9 @@ Más formalmente, Definimos:
       M \mapsto N \Longleftrightarrow \exists \underset{M \to N}{C} \in G
 
 *Live set*
       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.
+   Es 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::
 
 
    .. math::
 
@@ -245,20 +228,20 @@ Más formalmente, Definimos:
       \right\rbrace
 
 *Basura*
       \right\rbrace
 
 *Basura*
-   la basura, o celdas *muertas*, quedan determinadas entonces por todas las
+   La basura, o celdas *muertas*, quedan determinadas entonces por todas las
    celdas del *heap* que no son parte del *live set*.
 
    .. math::
 
       Basura = V - Live \thickspace set
 
    celdas del *heap* que no son parte del *live set*.
 
    .. math::
 
       Basura = V - Live \thickspace set
 
-Esto es, efectivamente, una partición del *heap* (ver figura
+El *Live set* y la *Basura* conforman una partición del *heap* (ver figura
 :vref:`fig:gc-heap-parts`).
 
 
 :vref:`fig:gc-heap-parts`).
 
 
-.. fig:: fig:gc-heap-parts
+.. flt:: fig:gc-heap-parts
 
 
-   Distintas partes de la memoria *heap*.
+   Distintas partes de la memoria *heap*
 
    Distintas partes de la memoria, incluyendo relación entre *basura*, *live
    set*, *heap* y *root set*.
 
    Distintas partes de la memoria, incluyendo relación entre *basura*, *live
    set*, *heap* y *root set*.
@@ -318,18 +301,13 @@ 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
 
 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*)
-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 el rendimiento, 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*.
+es necesario marcar los vértices para evitar visitar dos veces el mismo nodo
+en casos en los que el grafo contenga ciclos. 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 el
+rendimiento, en particular dependiendo de la aplicación puede convenir uno
+u otro método para lograr una mejor localidad de referencia.
 
 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)
@@ -338,7 +316,7 @@ siguiente (asumiendo que partimos con todos los vértices sin marcar)
    function mark(v) is
       if not v.marked
          v.marked = true
    function mark(v) is
       if not v.marked
          v.marked = true
-         for (src, dst) in v.edges
+         foreach (src, dst) in v.edges
             mark(dst)
 
    function mark_phase() is
             mark(dst)
 
    function mark_phase() is
@@ -366,11 +344,11 @@ con el marcado del grafo completo, dejando sin marcar solamente las celdas
 *basura* (en blanco).
 
 
 *basura* (en blanco).
 
 
-.. fig:: fig:gc-mark-1
+.. flt:: fig:gc-mark-1
 
 
-   Ejemplo de marcado del grafo de conectividad (parte 1).
+   Ejemplo de marcado del grafo de conectividad (parte 1)
 
 
-   .. subfig::
+   .. subflt::
 
       Se comienza a marcar el grafo por la raíz r0.
 
 
       Se comienza a marcar el grafo por la raíz r0.
 
@@ -403,7 +381,7 @@ con el marcado del grafo completo, dejando sin marcar solamente las celdas
 
          }
 
 
          }
 
-   .. subfig::
+   .. subflt::
 
       Luego de marcar el nodo ``h1``, se procede al ``h2``.
 
 
       Luego de marcar el nodo ``h1``, se procede al ``h2``.
 
@@ -437,7 +415,7 @@ con el marcado del grafo completo, dejando sin marcar solamente las celdas
 
          }
 
 
          }
 
-   .. subfig::
+   .. subflt::
 
       Luego sigue el nodo h5.
 
 
       Luego sigue el nodo h5.
 
@@ -473,11 +451,11 @@ con el marcado del grafo completo, dejando sin marcar solamente las celdas
          }
 
 
          }
 
 
-.. fig:: fig:gc-mark-2
+.. flt:: fig:gc-mark-2
 
 
-   Ejemplo de marcado del grafo de conectividad (parte 2).
+   Ejemplo de marcado del grafo de conectividad (parte 2)
 
 
-   .. subfig::
+   .. subflt::
 
       El nodo h5 tiene una arista al h1, pero el h1 ya fue visitado, por lo
       tanto no se visita nuevamente.
 
       El nodo h5 tiene una arista al h1, pero el h1 ya fue visitado, por lo
       tanto no se visita nuevamente.
@@ -513,7 +491,7 @@ con el marcado del grafo completo, dejando sin marcar solamente las celdas
 
          }
 
 
          }
 
-   .. subfig::
+   .. subflt::
 
       Se concluye el marcado del sub-grafo al que conecta r0, se procede
       a marcar el sub-grafo al que conecta r1, marcando al nodo h6.
 
       Se concluye el marcado del sub-grafo al que conecta r0, se procede
       a marcar el sub-grafo al que conecta r1, marcando al nodo h6.
@@ -550,7 +528,7 @@ con el marcado del grafo completo, dejando sin marcar solamente las celdas
 
          }
 
 
          }
 
-   .. subfig::
+   .. subflt::
 
       El nodo h6 tiene una arista al h2, pero éste ya fue marcado por lo
       que no se vuelve a visitar. No hay más raíces, se finaliza el marcado
 
       El nodo h6 tiene una arista al h2, pero éste ya fue marcado por lo
       que no se vuelve a visitar. No hay más raíces, se finaliza el marcado
@@ -609,10 +587,11 @@ 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
 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*.
+a una celda blanca** (considerando como atómica la operación de pintar una
+celda de negro y a sus hijas directas de gris). 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
 
 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
@@ -625,16 +604,16 @@ vacíos)::
       while not gray_set.empty()
          v = gray_set.pop()
          black_set.add(v)
       while not gray_set.empty()
          v = gray_set.pop()
          black_set.add(v)
-         for (src, dst) in v.edges
+         foreach (src, dst) in v.edges
             if dst in white_set
                white_set.remove(dst)
                gray_set.add(dst)
 
 Si bien este algoritmo no es recursivo, tiene un requerimiento de espacio
 :math:`O(\lvert Live \thickspace set \rvert)`. Un ejemplo donde se aprecia
             if dst in white_set
                white_set.remove(dst)
                gray_set.add(dst)
 
 Si bien este algoritmo no es recursivo, tiene un requerimiento de espacio
 :math:`O(\lvert Live \thickspace set \rvert)`. Un ejemplo donde se aprecia
-esto a simple vista es cuando el *live set* resulta una lista simplemente
-enlazada, en cuyo caso el :math:`gray_set` deberá almacenar todos los nodos
-del *live set*.
+esto a simple vista es cuando el *Live set* resulta una lista simplemente
+enlazada, en cuyo caso el *gray_set* deberá almacenar todos los nodos del
+*Live set*.
 
 
 
 
 
 
@@ -664,7 +643,7 @@ recolectores a lo largo de este documento.
 Servicios utilizados por el recolector son los siguientes:
 
 :math:`alloc() \to cell`
 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
+   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
    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
@@ -677,16 +656,16 @@ Servicios utilizados por el recolector son los siguientes:
    puede ser fácilmente relajada (en los recolectores que la tienen).
 
 :math:`free(cell)`
    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
+   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:
 
 :math:`new() \to cell`
    sido obtenida mediante ``alloc()``.
 
 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.
+   Obtiene una celda de memoria para ser utilizada por el programa.
 
 :math:`update(ref, cell)`
 
 :math:`update(ref, cell)`
-   notifica al recolector que la referencia :math:`ref` ahora apunta
+   Notifica al recolector que la referencia :math:`ref` ahora apunta
    a :math:`cell`. Visto más formalmente, sería análogo a decir que hubo un
    cambio en la conectividad del grafo: la arista :math:`src \to old` cambia
    por :math:`src \to new` (donde :math:`src` es la celda que contiene la
    a :math:`cell`. Visto más formalmente, sería análogo a decir que hubo un
    cambio en la conectividad del grafo: la arista :math:`src \to old` cambia
    por :math:`src \to new` (donde :math:`src` es la celda que contiene la
@@ -696,19 +675,20 @@ Y los servicios básicos proporcionados por el recolector son los siguientes:
    :math:`src \to old`.
 
 :math:`del(cell)`
    :math:`src \to old`.
 
 :math:`del(cell)`
-   este servicio, según el algoritmo, puede ser utilizado para informar un
+   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 <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
    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`.
+   Live \thickspace set , w \in Live \thickspace set \big/ w = cell
+   \big\rbrace`.
 
 :math:`collect()`
 
 :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.
+   Este servicio 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.
 
 No todos los servicios son implementados por todos los recolectores, pero son
 lo suficientemente comunes como para describirlos de forma general en esta
 
 No todos los servicios son implementados por todos los recolectores, pero son
 lo suficientemente comunes como para describirlos de forma general en esta
@@ -722,7 +702,7 @@ aunque en ciertas circunstancias pueden ser utilizados por el usuario también.
 Algoritmos clásicos
 ----------------------------------------------------------------------------
 
 Algoritmos clásicos
 ----------------------------------------------------------------------------
 
-En la literatura se encuentran normalmente referencias a 3 algoritmos
+En la literatura se encuentran normalmente referencias a tres 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.
@@ -815,31 +795,29 @@ 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
 
 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*.
+grafo de conectividad, hay una pérdida de memoria potencial en el programa.
 
 Cuando esto sucede, las celdas que participan del ciclo tienen siempre su
 
 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 para la cual hayan referencias
-desde el ciclo pero que no tenga otras referencias externas) y sin embargo los
+contador mayor que 0, sin embargo puede suceder que ningún elemento del *root
+set* apunte a una celda dentro del ciclo, por lo tanto el ciclo es *basura*
+(al igual que cualquier otra celda para la cual hayan referencias desde el
+ciclo pero que no tenga otras referencias externas) y sin embargo los
 contadores no son 0. Los ciclos, por lo tanto, violan 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 sub-grafo para detectar
 contadores no son 0. Los ciclos, por lo tanto, violan 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 sub-grafo 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.
+ciclos y liberarlos hasta tener otro recolector completo de *emergencia*;
+pasando por tratar los ciclos como un todo para 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
 
 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]_.
+[PHP530]_.
 
 
 .. _gc_rc_example:
 
 
 .. _gc_rc_example:
@@ -862,13 +840,13 @@ 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`).
 
 *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
+.. flt:: fig:gc-rc-rm-1
 
 
-   Ejemplo de conteo de referencias: eliminación de una referencia (parte 1).
+   Ejemplo de conteo de referencias: eliminación de una referencia (parte 1)
 
    Eliminación de la referencia ``r0`` :math:`\to` ``h1`` (parte 1).
 
 
    Eliminación de la referencia ``r0`` :math:`\to` ``h1`` (parte 1).
 
-   .. subfig::
+   .. subflt::
 
       Estado inicial del grafo de conectividad.
 
 
       Estado inicial del grafo de conectividad.
 
@@ -915,7 +893,7 @@ conduce al decremento del contador de ``h2`` y ``h3`` que permanecen en el
 
          }
 
 
          }
 
-   .. subfig::
+   .. subflt::
 
       Al ejecutarse ``update(r0, null)``, se comienza por visitar la celda
       ``h1``.
 
       Al ejecutarse ``update(r0, null)``, se comienza por visitar la celda
       ``h1``.
@@ -963,7 +941,7 @@ conduce al decremento del contador de ``h2`` y ``h3`` que permanecen en el
 
          }
 
 
          }
 
-   .. subfig::
+   .. subflt::
 
       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``.
@@ -1017,14 +995,14 @@ conduce al decremento del contador de ``h2`` y ``h3`` que permanecen en el
          }
 
 
          }
 
 
-.. fig:: fig:gc-rc-rm-2
+.. flt:: fig:gc-rc-rm-2
    :padding: 0.5
 
    :padding: 0.5
 
-   Ejemplo de conteo de referencias: eliminación de una referencia (parte 2).
+   Ejemplo de conteo de referencias: eliminación de una referencia (parte 2)
 
    Eliminación de la referencia ``r0`` :math:`\to` ``h1`` (parte 2).
 
 
    Eliminación de la referencia ``r0`` :math:`\to` ``h1`` (parte 2).
 
-   .. subfig::
+   .. subflt::
 
       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*).
@@ -1077,7 +1055,7 @@ conduce al decremento del contador de ``h2`` y ``h3`` que permanecen en el
 
          }
 
 
          }
 
-   .. subfig::
+   .. subflt::
 
       El contador de ``h3`` tampoco queda en 0, sigue en el *live set*.
 
 
       El contador de ``h3`` tampoco queda en 0, sigue en el *live set*.
 
@@ -1137,14 +1115,14 @@ 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`).
 
 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
+.. flt:: fig:gc-rc-up-1
 
 
-   Ejemplo de conteo de referencias: actualización de una referencia (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`
+   Cambio en la referencia ``h3.l`` :math:`\to` ``h2`` a ``h3.l`` :math:`\to`
    ``h5`` (parte 1).
 
    ``h5`` (parte 1).
 
-   .. subfig::
+   .. subflt::
 
       Comienza ``update(h3.l, h5)``, se incrementa el contador de ``h5``.
 
 
       Comienza ``update(h3.l, h5)``, se incrementa el contador de ``h5``.
 
@@ -1197,9 +1175,9 @@ contador de ``h2`` que queda en 0, transformándose en *basura* (ver figura
 
          }
 
 
          }
 
-   .. subfig::
+   .. subflt::
 
 
-      Luego se procede a visitar las hijas de ``h3``, comenzando por ``h2``.
+      Luego se procede a visitar la antigua referencia de ``h3.l`` (``h2``).
 
       .. digraph:: g4_2
 
 
       .. digraph:: g4_2
 
@@ -1250,7 +1228,7 @@ contador de ``h2`` que queda en 0, transformándose en *basura* (ver figura
 
          }
 
 
          }
 
-   .. subfig::
+   .. subflt::
 
       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.
@@ -1285,7 +1263,7 @@ contador de ``h2`` que queda en 0, transformándose en *basura* (ver figura
             };
 
             h1 [ label = "h1\n0|<l> l|<r> r" ];
             };
 
             h1 [ label = "h1\n0|<l> l|<r> r" ];
-            h2 [ label = "h2\n1|<l> l|<r> r" ];
+            h2 [ label = "h2\n0|<l> l|<r> r" ];
             h3 [ label = "h3\n2|<l> l\n*|<r> r" ];
             h4 [ label = "h4\n1|<l> l|<r> r" ];
             h5 [ label = "h5\n2|<l> l|<r> r" ];
             h3 [ label = "h3\n2|<l> l\n*|<r> r" ];
             h4 [ label = "h4\n1|<l> l|<r> r" ];
             h5 [ label = "h5\n2|<l> l|<r> r" ];
@@ -1311,14 +1289,14 @@ a apuntar a ``h5``) así que permanece en el *live set*. Finalmente se termina
 de actualizar la referencia ``h3.l`` para que apunte a ``h5`` (ver figura
 :vref:`fig:gc-rc-up-2`).
 
 de actualizar la referencia ``h3.l`` para que apunte a ``h5`` (ver figura
 :vref:`fig:gc-rc-up-2`).
 
-.. fig:: fig:gc-rc-up-2
+.. flt:: fig:gc-rc-up-2
 
 
-   Ejemplo de conteo de referencias: actualización de una referencia (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`
+   Cambio en la referencia ``h3.l`` :math:`\to` ``h2`` a ``h3.l`` :math:`\to`
    ``h5`` (parte 2).
 
    ``h5`` (parte 2).
 
-   .. subfig::
+   .. subflt::
 
       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``.
@@ -1353,7 +1331,7 @@ de actualizar la referencia ``h3.l`` para que apunte a ``h5`` (ver figura
             };
 
             h1 [ label = "h1\n0|<l> l|<r> r" ];
             };
 
             h1 [ label = "h1\n0|<l> l|<r> r" ];
-            h2 [ label = "h2\n1|<l> l|<r> r" ];
+            h2 [ label = "h2\n0|<l> l|<r> r" ];
             h3 [ label = "h3\n2|<l> l\n*|<r> r" ];
             h4 [ label = "h4\n0|<l> l|<r> r" ];
             h5 [ label = "h5\n2|<l> l|<r> r" ];
             h3 [ label = "h3\n2|<l> l\n*|<r> r" ];
             h4 [ label = "h4\n0|<l> l|<r> r" ];
             h5 [ label = "h5\n2|<l> l|<r> r" ];
@@ -1372,7 +1350,7 @@ de actualizar la referencia ``h3.l`` para que apunte a ``h5`` (ver figura
 
          }
 
 
          }
 
-   .. subfig::
+   .. subflt::
 
       Se decrementa el contador de ``h5`` pero sigue siendo mayor que 0.
 
 
       Se decrementa el contador de ``h5`` pero sigue siendo mayor que 0.
 
@@ -1406,7 +1384,7 @@ de actualizar la referencia ``h3.l`` para que apunte a ``h5`` (ver figura
             };
 
             h1 [ label = "h1\n0|<l> l|<r> r" ];
             };
 
             h1 [ label = "h1\n0|<l> l|<r> r" ];
-            h2 [ label = "h2\n1|<l> l|<r> r" ];
+            h2 [ label = "h2\n0|<l> l|<r> r" ];
             h3 [ label = "h3\n2|<l> l\n*|<r> r" ];
             h4 [ label = "h4\n0|<l> l|<r> r" ];
             h5 [ label = "h5\n1|<l> l|<r> r" ];
             h3 [ label = "h3\n2|<l> l\n*|<r> r" ];
             h4 [ label = "h4\n0|<l> l|<r> r" ];
             h5 [ label = "h5\n1|<l> l|<r> r" ];
@@ -1425,7 +1403,7 @@ de actualizar la referencia ``h3.l`` para que apunte a ``h5`` (ver figura
 
          }
 
 
          }
 
-   .. subfig::
+   .. subflt::
 
       Se termina por actualizar la referencia de ``h3.l`` para que apunte
       a ``h5``.
 
       Se termina por actualizar la referencia de ``h3.l`` para que apunte
       a ``h5``.
@@ -1491,15 +1469,15 @@ 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`).
 
 pueden ser recicladas y su memoria es perdida (ver figura
 :vref:`fig:gc-rc-cycle`).
 
-.. fig:: fig:gc-rc-cycle
+.. flt:: fig:gc-rc-cycle
    :padding: 0.5
 
    :padding: 0.5
 
-   Ejemplo de conteo de referencias: 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).
 
 
    Eliminación de la referencia ``r1`` :math:`\to` ``h3`` (pérdida de memoria
    debido a un ciclo).
 
-   .. subfig::
+   .. subflt::
 
       El ejecutarse ``update(r1, null)`` se visita la celda ``h3``.
 
 
       El ejecutarse ``update(r1, null)`` se visita la celda ``h3``.
 
@@ -1553,7 +1531,7 @@ pueden ser recicladas y su memoria es perdida (ver figura
 
          }
 
 
          }
 
-   .. subfig::
+   .. subflt::
 
       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.
@@ -1702,9 +1680,9 @@ sus *low level allocators*).
    sucede y se acumulan muchos *huecos* se dice que la memoria está
    *fragmentada*.
 
    sucede y se acumulan muchos *huecos* se dice que la memoria está
    *fragmentada*.
 
-.. fig:: fig:gc-copy
+.. flt:: fig:gc-copy
 
 
-   Estructura del *heap* de un recolector con copia de semi-espacios.
+   Estructura del *heap* de un recolector con copia de semi-espacios
 
    .. aafig::
       :aspect: 70
 
    .. aafig::
       :aspect: 70
@@ -1752,13 +1730,13 @@ recolectores deben estar íntimamente relacionados con el *low level
 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
 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::
+4 variables globales: ``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
 
    function alloc(size) is
       if free + size > fromspace + spacesize
@@ -1786,6 +1764,7 @@ a asignar::
    function copy(cell) is
       if cell.forwarding_address is null
          cell.forwarding_address = free
    function copy(cell) is
       if cell.forwarding_address is null
          cell.forwarding_address = free
+         cell.copy_to(free)
          free = free + cell.size
          foreach child in cell
             child = copy(child)
          free = free + cell.size
          foreach child in cell
             child = copy(child)
@@ -1836,11 +1815,11 @@ apunta a ``h3``, por lo tanto ésta es movida al *Tospace* primero, dejando una
 *forwarding address* a la nueva ubicación (ver figura
 :vref:`fig:gc-copy-ex-1`).
 
 *forwarding address* a la nueva ubicación (ver figura
 :vref:`fig:gc-copy-ex-1`).
 
-.. fig:: fig:gc-copy-ex-1
+.. flt:: fig:gc-copy-ex-1
 
 
-   Ejemplo de recolección con copia de semi-espacios (parte 1).
+   Ejemplo de recolección con copia de semi-espacios (parte 1)
 
 
-   .. subfig::
+   .. subflt::
 
       Estructura inicial del *heap*. El *Fromspace* está complete y se inicial
       la recolección.
 
       Estructura inicial del *heap*. El *Fromspace* está complete y se inicial
       la recolección.
@@ -1871,7 +1850,7 @@ apunta a ``h3``, por lo tanto ésta es movida al *Tospace* primero, dejando una
          | "Tospace"                                        |
          +--------------------------------------------------+
 
          | "Tospace"                                        |
          +--------------------------------------------------+
 
-   .. subfig::
+   .. subflt::
 
       Se sigue la referencia del *root set*, copiando ``h3`` al *Tospace*
       y dejando una *forwarding address*.
 
       Se sigue la referencia del *root set*, copiando ``h3`` al *Tospace*
       y dejando una *forwarding address*.
@@ -1913,11 +1892,11 @@ sido visitada, solamente se actualiza la referencia apuntando a la nueva
 ubicación de ``h2`` pero no se vuelve a copiar la celda (ver figura
 :vref:`fig:gc-copy-ex-2`).
 
 ubicación de ``h2`` pero no se vuelve a copiar la celda (ver figura
 :vref:`fig:gc-copy-ex-2`).
 
-.. fig:: fig:gc-copy-ex-2
+.. flt:: fig:gc-copy-ex-2
 
 
-   Ejemplo de recolección con copia de semi-espacios (parte 2).
+   Ejemplo de recolección con copia de semi-espacios (parte 2)
 
 
-   .. subfig::
+   .. subflt::
 
       Se sigue :math:`h3 \to h2`, copiando ``h2`` al *Tospace* y dejando una
       *forwarding address*.
 
       Se sigue :math:`h3 \to h2`, copiando ``h2`` al *Tospace* y dejando una
       *forwarding address*.
@@ -1948,7 +1927,7 @@ ubicación de ``h2`` pero no se vuelve a copiar la celda (ver figura
          | "Tospace"                                        |
          +--------------------------------------------------+
 
          | "Tospace"                                        |
          +--------------------------------------------------+
 
-   .. subfig::
+   .. subflt::
 
       Se sigue :math:`h2 \to h1`, copiando ``h1``. Luego :math:`h1 \to h2`
       pero ``h2`` no se copia, sólo se actualiza la referencia con la
 
       Se sigue :math:`h2 \to h1`, copiando ``h1``. Luego :math:`h1 \to h2`
       pero ``h2`` no se copia, sólo se actualiza la referencia con la
@@ -1987,11 +1966,11 @@ semi-espacios y se actualiza la referencia del *root set* para que apunte a la
 nueva ubicación de ``h3``, como se muestra en la figura
 :vref:`fig:gc-copy-ex-3`.
 
 nueva ubicación de ``h3``, como se muestra en la figura
 :vref:`fig:gc-copy-ex-3`.
 
-.. fig:: fig:gc-copy-ex-3
+.. flt:: fig:gc-copy-ex-3
 
 
-   Ejemplo de recolección con copia de semi-espacios (parte 3).
+   Ejemplo de recolección con copia de semi-espacios (parte 3)
 
 
-   .. subfig::
+   .. subflt::
 
       Se sigue :math:`h1 \to h4` copiando `h4`` al *Tospace* y dejando una
       *forwarding address*.
 
       Se sigue :math:`h1 \to h4` copiando `h4`` al *Tospace* y dejando una
       *forwarding address*.
@@ -2022,7 +2001,7 @@ nueva ubicación de ``h3``, como se muestra en la figura
          | "Tospace"   \------/                             |
          +--------------------------------------------------+
 
          | "Tospace"   \------/                             |
          +--------------------------------------------------+
 
-   .. subfig::
+   .. subflt::
 
       Se finaliza la recolección, se intercambian los roles de los
       semi-espacios y se actualiza la referencia del *root set*.
 
       Se finaliza la recolección, se intercambian los roles de los
       semi-espacios y se actualiza la referencia del *root set*.
@@ -2120,13 +2099,9 @@ 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*.
 *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 <gc_rc>` (directa) y *traicing garbage collection* (indirecta).
 Prácticamente todos los recolectores menos el :ref:`conteo de referencias
 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>`).
+<gc_rc>` están dentro de esta 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*
 
 Otros ejemplos de recolectores modernos *directos* son el recolector de basura
 de Python_ [NAS00]_ y [LINS05]_ (aunque ambos tiene un algoritmo *indirecto*
@@ -2183,12 +2158,12 @@ 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`).
 
 disponibles para realizar la recolección (ver figura
 :vref:`fig:gc-concurrent`).
 
-.. fig:: fig:gc-concurrent
+.. flt:: fig:gc-concurrent
 
    Distintos tipos de recolectores según el comportamiento en ambientes
 
    Distintos tipos de recolectores según el comportamiento en ambientes
-   multi-hilo.
+   multi-hilo
 
 
-   .. subfig::
+   .. subflt::
 
       *Stop-the-world*.
 
 
       *Stop-the-world*.
 
@@ -2207,7 +2182,7 @@ disponibles para realizar la recolección (ver figura
          |         HH Mutator           ZZ Inactivo         XX Recolector    |
          |___________________________________________________________________|
 
          |         HH Mutator           ZZ Inactivo         XX Recolector    |
          |___________________________________________________________________|
 
-   .. subfig::
+   .. subflt::
 
       Paralelo.
 
 
       Paralelo.
 
@@ -2226,7 +2201,7 @@ disponibles para realizar la recolección (ver figura
          |         HH Mutator           ZZ Inactivo         XX Recolector    |
          |___________________________________________________________________|
 
          |         HH Mutator           ZZ Inactivo         XX Recolector    |
          |___________________________________________________________________|
 
-   .. subfig::
+   .. subflt::
 
       Concurrente.
 
 
       Concurrente.
 
@@ -2257,12 +2232,12 @@ 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.
 
 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
+¿Cl es la idea entonces de un recolector concurrente? Una vez más, al igual
 que los recolectores incrementales, el principal objetivo es disminuir las
 largas pausas provocadas por la recolección de basura. Sin embargo, este tipo
 de algoritmos además permite hacer un mejor aprovechamiento de las
 que los recolectores incrementales, el principal objetivo es disminuir las
 largas pausas provocadas por la recolección de basura. Sin embargo, este tipo
 de algoritmos además permite hacer un mejor aprovechamiento de las
-arquitecturas *multi-core* [#gcmulticore]_ que cada vez se afirman más, ya que
-el *mutator* y el recolector pueden estar corriendo realmente en paralelo,
+arquitecturas *multi-core* [#gcmulticore]_ que cada vez son más comunes, ya
+que el *mutator* y el recolector pueden estar corriendo realmente en paralelo,
 cada uno en un procesador distinto. Algunos recolectores van más allá
 y permiten incluso paralelizar la recolección de basura en varios hilos
 ([HUEL98]_, [LINS05]_). Otros ejemplos de recolectores concurrentes (aunque no
 cada uno en un procesador distinto. Algunos recolectores van más allá
 y permiten incluso paralelizar la recolección de basura en varios hilos
 ([HUEL98]_, [LINS05]_). Otros ejemplos de recolectores concurrentes (aunque no
@@ -2354,17 +2329,17 @@ 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
 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 <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
-recolector de este tipo [MOLAWE]_ [MOLA06]_.
+semi-espacios <gc_copy>` pero suele proveer una mayor localidad de referencia
+y no *desperdicia* un semi-espacio que está inutilizado salvo en el momento de
+la recolección. Por ejemplo para Mono_, que antes usaba un recolector
+conservativo sin movimiento ([BOEHWD]_) se está implementando un recolector de
+este tipo [MOLAWE]_ [MOLA06]_.
 
 
 
 .. _gc_conserv:
 
 
 
 
 .. _gc_conserv:
 
-Recolectores conservativos vs precisos
+Recolectores conservativos versus precisos
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Los recolectores *conservativos* son aquellos que tienen la capacidad de poder
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Los recolectores *conservativos* son aquellos que tienen la capacidad de poder
@@ -2375,8 +2350,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
 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:`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`), dado que no pueden actualizar los supuestos
+punteros por la posibilidad 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.
 
 .. [#gcflasepos] Esto es lo que se conoce como un *falso positivo*, algo que
    aparenta ser un puntero pero en realidad no lo es.
@@ -2424,11 +2399,11 @@ haya.
 
 Entonces, si el recolector tiene algún mecanismo para identificar zonas de
 alta concentración de *basura* puede hacer la recolección solo en ese área
 
 Entonces, si el recolector tiene algún mecanismo para identificar zonas de
 alta concentración de *basura* puede hacer la recolección solo en ese área
-donde el trabajo va a ser mejor recompensado (ver :vref:`fig:gc-part`).
+donde el trabajo va a ser mejor recompensado (ver figura :vref:`fig:gc-part`).
 
 
-.. fig:: fig:gc-part
+.. flt:: fig:gc-part
 
 
-   Concentración de basura en distintas particiones del *heap*.
+   Concentración de basura en distintas particiones del *heap*
 
    .. aafig::
       :scale: 110
 
    .. aafig::
       :scale: 110
@@ -2473,7 +2448,7 @@ completo).
 
 Sin embargo, a pesar de ser este el esquema más difundido para dividir el
 *heap* y realizar una recolección parcial sobre un área de alta concentración
 
 Sin embargo, a pesar de ser este el esquema más difundido para dividir el
 *heap* y realizar una recolección parcial sobre un área de alta concentración
-de basura no es la única. Otros recolectores proponen hacer un análisis
+de basura, no es la única. Otros recolectores proponen hacer un análisis
 estático del código revisando la conectividad entre los objetos según sus
 tipos (esto es posible solo en lenguajes con *tipado* estático), de manera tal
 de separar en distintas áreas grupos de tipos que no pueden tener referencias
 estático del código revisando la conectividad entre los objetos según sus
 tipos (esto es posible solo en lenguajes con *tipado* estático), de manera tal
 de separar en distintas áreas grupos de tipos que no pueden tener referencias