Mejorar estilo de página de resumen/agradecimientos

[z.facultad/75.00/informe.git] / source / gc.rst

diff --git a/source/gc.rst b/source/gc.rst
index a1eb36080314e62a361ad32bfef5f7e8364a45a7..ff79b4fd35994a13242ca71f836f75ed49d88384 100644 (file)
--- a/source/gc.rst
+++ b/source/gc.rst
@@ -66,12 +66,12 @@ recolectores de basura (aunque no se limitaron a este lenguaje las
 investigaciones).
 
 En las primeras implementaciones de recolectores de basura la penalización en
 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
+el rendimiento 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
 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
+alternativa más viable al manejo manual de memoria, incluso para aplicaciones
+con altos requerimientos de rendimiento. En la actualidad un programa que
+utiliza un recolector moderno puede ser comparable en rendimiento 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
 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


@@ -95,13 +95,14 @@ errores.
 
 
 
 
 
 

+.. _gc_intro_basics:

 
 Conceptos básicos
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Los programas pueden hacer uso principalmente de 4 áreas de memoria:
 
 
 Conceptos básicos
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Los programas pueden hacer uso principalmente de 4 áreas de memoria:
 

-Registros:
+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
    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


@@ -109,7 +110,7 @@ Registros:
    realizando tareas de muy bajo nivel, un programador nunca manipula los
    registros explícitamente.
 
    realizando tareas de muy bajo nivel, un programador nunca manipula los
    registros explícitamente.
 

-Área de memoria estática:
+Á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
    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


@@ -119,7 +120,7 @@ Registros:
    compilación**. Los primeros lenguajes de programación solo contaban con
    este tipo de memoria (además de los registros del procesador).
 
    compilación**. Los primeros lenguajes de programación solo contaban con
    este tipo de memoria (además de los registros del procesador).
 

-*Stack* (pila):
+*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
    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


@@ -137,7 +138,7 @@ Registros:
       a otra cosa, como al nodo de una lista o a un objeto en el sentido de
       programación orientada a objetos).
 
       a otra cosa, como al nodo de una lista o a un objeto en el sentido de
       programación orientada a objetos).
 

-*Heap*:
+*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
    memoria más flexible y por lo tanto el más complejo de administrar; razón
    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


@@ -155,22 +156,6 @@ 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


@@ -181,11 +166,10 @@ 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
 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).
+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í. 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.

 
 
 
 
 
 


@@ -211,7 +195,7 @@ fueron visitados componen el *live set*; el resto de los vértices son
 
 Más formalmente, Definimos:
 
 
 Más formalmente, Definimos:
 

-*Camino*:
+*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*).
    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*).


@@ -224,7 +208,12 @@ 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
 

-*Conexión*:
+   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*

    decimos que :math:`M` está *conectado* a :math:`N` si y sólo si existe un
    camino de :math:`M` a :math:`N`.
 
    decimos que :math:`M` está *conectado* a :math:`N` si y sólo si existe un
    camino de :math:`M` a :math:`N`.
 


@@ -232,7 +221,7 @@ Más formalmente, Definimos:
 
       M \mapsto N \Longleftrightarrow \exists \underset{M \to N}{C} \in G
 
 
       M \mapsto N \Longleftrightarrow \exists \underset{M \to N}{C} \in G
 

-*Live set*:
+*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.


@@ -243,7 +232,7 @@ Más formalmente, Definimos:
          \left( \exists r \in Root \thickspace set \big/ r \mapsto v \right)
       \right\rbrace
 
          \left( \exists r \in Root \thickspace set \big/ r \mapsto v \right)
       \right\rbrace
 

-*Basura*:
+*Basura*

    la basura, o celdas *muertas*, quedan determinadas entonces por todas las
    celdas del *heap* que no son parte del *live set*.
 
    la basura, o celdas *muertas*, quedan determinadas entonces por todas las
    celdas del *heap* que no son parte del *live set*.
 


@@ -255,9 +244,9 @@ Esto es, efectivamente, 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*.


@@ -317,27 +306,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
 
 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 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*.
-
-Un algoritmo simple (recursivo) de marcado *primero a lo alto*  puede ser el
+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)
 [#gcpseudo]_::
 
    function mark(v) is
       if not v.marked
          v.marked = true
 siguiente (asumiendo que partimos con todos los vértices sin marcar)
 [#gcpseudo]_::
 
    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


@@ -365,11 +349,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.
 


@@ -402,7 +386,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``.
 


@@ -436,7 +420,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.
 


@@ -472,11 +456,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.


@@ -512,7 +496,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.


@@ -549,7 +533,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


@@ -598,11 +582,11 @@ 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 <gc_concurrent>` e :ref:`incrementales
 <gc_inc>`, además de otro tipo de optimizaciones.  Entonces, lo que plantea
 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.
+esta abstracción es una nueva partición del heap al momento de marcar, esta
+vez son tres porciones: blanca, gris y negra.

 
 Al principio todas las celdas se pintan de blanco, excepto el *root set* que
 
 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
+se pinta 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
 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


@@ -624,13 +608,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
-            if v in white_set
-               white_set.remove(v)
-               gray_set.add(v)
+         foreach (src, dst) in v.edges
+            if dst in white_set
+               white_set.remove(dst)
+               gray_set.add(dst)

 
 

-Es simple notar que este algoritmo es naturalmente no recursivo, lo que de por
-sí ya presenta una ventaja sobre el marcado *bicolor*.
+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 *gray_set* deberá almacenar todos los nodos del
+*Live set*.

 
 
 
 
 
 


@@ -659,7 +646,7 @@ recolectores a lo largo de este documento.
 
 Servicios utilizados por el recolector son los siguientes:
 
 
 Servicios utilizados por el recolector son los siguientes:
 

-:math:`alloc() \to cell`:
+: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
    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


@@ -672,16 +659,16 @@ Servicios utilizados por el recolector son los siguientes:
    contrario) que las celdas son de tamaño fijo. Esta restricción normalmente
    puede ser fácilmente relajada (en los recolectores que la tienen).
 
    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)`:
+:math:`free(cell)`

    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:
 
    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`:
+: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
    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
    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


@@ -691,7 +678,7 @@ Y los servicios básicos proporcionados por el recolector son los siguientes:
    :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)`:
+: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
    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


@@ -699,9 +686,10 @@ Y los servicios básicos proporcionados por el recolector son los siguientes:
    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
    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.
    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.


@@ -718,7 +706,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.


@@ -811,31 +799,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 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.
+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
 
 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.
+esto son variados y van desde realizar un marcado del sub-grafo para detectar
+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:


@@ -847,7 +833,7 @@ A continuación se presenta un ejemplo gráfico para facilitar la comprensión
 del algoritmo. Por simplicidad se asumen celdas de tamaño fijo con dos
 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
 del algoritmo. Por simplicidad se asumen celdas de tamaño fijo con dos
 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
+estructura ya construida 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*.
 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*.


@@ -858,13 +844,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.
 


@@ -911,7 +897,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``.


@@ -959,7 +945,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``.


@@ -1013,14 +999,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*).


@@ -1073,7 +1059,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*.
 


@@ -1133,14 +1119,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``.
 


@@ -1193,9 +1179,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
 


@@ -1246,7 +1232,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.


@@ -1307,14 +1293,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``.


@@ -1368,7 +1354,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.
 


@@ -1421,7 +1407,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``.


@@ -1487,15 +1473,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``.
 


@@ -1549,7 +1535,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.


@@ -1687,15 +1673,24 @@ utiliza para asignar nuevas celdas de forma lineal, asumiendo un *heap*
 contiguo, incrementando un puntero (ver figura :vref:`fig:gc-copy`).  Esto se
 conoce como *pointer bump allocation* y es, probablemente, la forma más
 eficiente de asignar memoria (tan eficiente como asignar memoria en el
 contiguo, incrementando un puntero (ver figura :vref:`fig:gc-copy`).  Esto se
 conoce como *pointer bump allocation* y es, probablemente, la forma más
 eficiente de asignar memoria (tan eficiente como asignar memoria en el

-*stack*).
+*stack*). Esto permite además evitar el problema de la *fragmentación* de
+memoria [#gcfrag]_ que normalmente afectan a los otros algoritmos clásicos (o
+sus *low level allocators*).
+
+.. [#gcfrag] La *fragmentación* de memoria sucede cuando se asignan objetos
+   de distintos tamaños y luego libera alguno intermedio, produciendo
+   *huecos*. Estos *huecos* quedan inutilizables hasta que se quiera
+   asignar un nuevo objeto de tamaño igual al *hueco* (o menor). Si esto no
+   sucede y se acumulan muchos *huecos* se dice que la memoria está
+   *fragmentada*.

 
 

-.. fig:: fig:gc-copy
+.. 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::
 
    .. aafig::

-      :aspect: 0.7
-      :scale: 1.4
+      :aspect: 70
+      :scale: 115

 
       zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz
 
 
       zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz
 


@@ -1723,7 +1718,7 @@ celdas *vivas* del *Fromspace* al *Tospace* de manera contigua, como si
 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
 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
+re-direcció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:`gc_intro_mark`). Cuando se encuentra una celda que ya fue
 movida, simplemente se actualiza la referencia por la cual se llegó a esa
 address* sirve a su vez de marca, para no recorrer una celda dos veces (como
 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


@@ -1794,7 +1789,7 @@ Al igual que el :ref:`gc_mark_sweep` este algoritmo es :ref:`indirecto
 <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
 <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
+barrido) es que este método requiere una sola pasada y sobre las celdas vivas

 del *heap* solamente. La principal desventaja es copia memoria, lo que puede
 ser particularmente costoso, además de requerir, como mínimo, el doble de
 memoria de lo que el *mutator* realmente necesita. Esto puede traer en
 del *heap* solamente. La principal desventaja es copia memoria, lo que puede
 ser particularmente costoso, además de requerir, como mínimo, el doble de
 memoria de lo que el *mutator* realmente necesita. Esto puede traer en


@@ -1823,17 +1818,16 @@ 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.
 
       .. aafig::
 
       Estructura inicial del *heap*. El *Fromspace* está complete y se inicial
       la recolección.
 
       .. aafig::

-         :scale: 1.25

 
          +--------------------------------------------------+
          | "Fromspace"                                      |
 
          +--------------------------------------------------+
          | "Fromspace"                                      |


@@ -1859,13 +1853,12 @@ 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*.
 
       .. aafig::
 
       Se sigue la referencia del *root set*, copiando ``h3`` al *Tospace*
       y dejando una *forwarding address*.
 
       .. aafig::

-         :scale: 1.25

 
          +--------------------------------------------------+
          | "Fromspace"                                      |
 
          +--------------------------------------------------+
          | "Fromspace"                                      |


@@ -1902,17 +1895,16 @@ 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*.
 
       .. aafig::
 
       Se sigue :math:`h3 \to h2`, copiando ``h2`` al *Tospace* y dejando una
       *forwarding address*.
 
       .. aafig::

-         :scale: 1.25

 
          +--------------------------------------------------+
          | "Fromspace"                                      |
 
          +--------------------------------------------------+
          | "Fromspace"                                      |


@@ -1938,14 +1930,13 @@ 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
       *forwarding address*.
 
       .. aafig::
 
       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
       *forwarding address*.
 
       .. aafig::

-         :scale: 1.25

 
          +--------------------------------------------------+
          | "Fromspace"                                      |
 
          +--------------------------------------------------+
          | "Fromspace"                                      |


@@ -1978,17 +1969,16 @@ 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*.
 
       .. aafig::
 
       Se sigue :math:`h1 \to h4` copiando `h4`` al *Tospace* y dejando una
       *forwarding address*.
 
       .. aafig::

-         :scale: 1.25

 
          +--------------------------------------------------+
          | "Fromspace"                                      |
 
          +--------------------------------------------------+
          | "Fromspace"                                      |


@@ -2014,13 +2004,12 @@ 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*.
 
       .. aafig::
 
       Se finaliza la recolección, se intercambian los roles de los
       semi-espacios y se actualiza la referencia del *root set*.
 
       .. aafig::

-         :scale: 1.25

 
          +--------------------------------------------------+
          | "Tospace"                                        |
 
          +--------------------------------------------------+
          | "Tospace"                                        |


@@ -2150,7 +2139,7 @@ la próxima iteración. Para realizar esto en recolectores :ref:`indirectos
 cuando el *mutator* cambia una referencia, se marca *gris* la celda que la
 contiene, de modo que el recolector vuelva a visitarla.
 
 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
+En general el rendimiento 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
 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


@@ -2176,17 +2165,18 @@ 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*.
 
       .. aafig::
 
       *Stop-the-world*.
 
       .. aafig::

-         :aspect: 0.7
+         :scale: 110
+         :aspect: 70

 
           ___________________________________________________________________
          |                                                                   |
 
           ___________________________________________________________________
          |                                                                   |


@@ -2199,12 +2189,13 @@ disponibles para realizar la recolección (ver figura
          |         HH Mutator           ZZ Inactivo         XX Recolector    |
          |___________________________________________________________________|
 
          |         HH Mutator           ZZ Inactivo         XX Recolector    |
          |___________________________________________________________________|
 

-   .. subfig::
+   .. subflt::

 
       Paralelo.
 
       .. aafig::
 
       Paralelo.
 
       .. aafig::

-         :aspect: 0.7
+         :scale: 110
+         :aspect: 70

 
           ___________________________________________________________________
          |                                                                   |
 
           ___________________________________________________________________
          |                                                                   |


@@ -2217,12 +2208,13 @@ disponibles para realizar la recolección (ver figura
          |         HH Mutator           ZZ Inactivo         XX Recolector    |
          |___________________________________________________________________|
 
          |         HH Mutator           ZZ Inactivo         XX Recolector    |
          |___________________________________________________________________|
 

-   .. subfig::
+   .. subflt::

 
       Concurrente.
 
       .. aafig::
 
       Concurrente.
 
       .. aafig::

-         :aspect: 0.7
+         :scale: 110
+         :aspect: 70

 
           ___________________________________________________________________
          |                                                                   |
 
           ___________________________________________________________________
          |                                                                   |


@@ -2247,12 +2239,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
+¿Cuál 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


@@ -2289,15 +2281,16 @@ 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
 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`.
+ineficiencias. El :ref:`marcado y barrido <gc_mark_sweep>` en general usa este
+esquema, al igual que el :ref:`conteo de referencias <gc_rc>`.

 
 Otro forma de organizar el *heap* es utilizándolo como una especie de *stack*
 en el cual para asignar simplemente se incrementa un puntero. Este esquema es
 simple y eficiente, si el recolector puede mover celdas (ver
 :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
 
 Otro forma de organizar el *heap* es utilizándolo como una especie de *stack*
 en el cual para asignar simplemente se incrementa un puntero. Este esquema es
 simple y eficiente, si el recolector puede mover celdas (ver
 :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:`gc_copy`.
+puntero). El clásico ejemplo de esta familia es el algoritmo visto en
+: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.
 
 Sin embargo, entre estos dos extremos, hay todo tipo de híbridos. Existen
 recolectores basados en *regiones*, que se encuentran en un punto intermedio.


@@ -2383,7 +2376,7 @@ para tener un recolector de basura (y en especial aquellos que son de relativo
 alto nivel) en general disponen de recolectores precisos.
 
 Hay casos donde se posee información de tipos para algunas celdas solamente,
 alto nivel) en general disponen de recolectores precisos.
 
 Hay casos donde se posee información de tipos para algunas celdas solamente,

-o más comunmente se posee información de tipos de celdas que se encuentran en
+o más comúnmente se posee información de tipos de celdas que se encuentran en

 el *heap* pero no para el *stack* y registros (por ejemplo [MOLA06]_). En
 estos casos se puede adoptar un esquema híbrido y tratar algunas referencias
 de forma conservativa y otras de forma precisa, de manera de mitigar, aunque
 el *heap* pero no para el *stack* y registros (por ejemplo [MOLA06]_). En
 estos casos se puede adoptar un esquema híbrido y tratar algunas referencias
 de forma conservativa y otras de forma precisa, de manera de mitigar, aunque


@@ -2396,30 +2389,32 @@ 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
 `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 <dgc_actual>` y [BLAC08]_.
+el usuario). Otros ejemplos de recolectores con cierto grado de precisión son
+el :ref:`recolector actual de D <dgc_actual>` y [BLAC08]_.

 
 
 
 .. _gc_part:
 
 
 
 
 .. _gc_part:
 

-Recolección particionada / generacional
+Recolección por particiones / generacional

 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Otra forma de reducir la cantidad de pausas y la cantidad de trabajo realizado
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Otra forma de reducir la cantidad de pausas y la cantidad de trabajo realizado

-por el recolector en general es particionando el *heap* de manera tal de
-recolectar solo las partes donde más probabilidad de encontrar *basura* haya.
+por el recolector en general es dividiendo el *heap* en particiones de manera
+tal de recolectar solo las partes donde más probabilidad de encontrar *basura*
+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::
 
    .. aafig::

-      :aspect: 0.7
+      :scale: 110
+      :aspect: 70

 
        _______________________________________________________________________
       |                                                                       |
 
        _______________________________________________________________________
       |                                                                       |


@@ -2434,44 +2429,44 @@ donde el trabajo va a ser mejor recompensado (ver :vref:`fig:gc-part`).
 
 
 Sin embargo encontrar zonas de alta concentración no es trivial. La forma más
 
 
 Sin embargo encontrar zonas de alta concentración no es trivial. La forma más

-divulgada de encontrar estas zonas es particionando el *heap* en un área
+divulgada de encontrar estas zonas es dividiendo el *heap* en una partición

 utilizada para almacenar celdas *jóvenes* y otra para celdas *viejas*. Una
 utilizada para almacenar celdas *jóvenes* y otra para celdas *viejas*. Una

-celda *vieja* es aquella que ha *sobrevivido* una cantidad N de recolecciones,
-mientras que el resto se consideran *jóvenes* (las celdas *nacen* jóvenes).
-Los recolectores que utilizan este tipo de partición son ampliamente conocido
-como recolectores **generacionales**. La *hipótesis generacional* dice que el
-área de celdas jóvenes tiene una mayor probabilidad de ser un área de alta
-concentración de basura [JOLI96]_. Basandose en esto, los recolectores
-generacionales primero intentan recuperar espacio del área de celdas jóvenes
-y luego, de ser necesario, del área de celdas viejas. Es posible tener varias
-generaciones e ir subiendo de generación a generación a medida que es
-necesario. Sin embargo en general no se obtienen buenos resultados una vez que
-se superan las 3 particiones. La complejidad que trae este método es que para
-recolectar la generación joven es necesario tomar las referencias de la
-generación vieja a la joven como parte del *root set* (de otra forma podrían
-tomarse celdas como *basura* que todavía son utilizadas por las celdas
-viejas). Revisar toda la generación vieja no es una opción porque sería
-prácticamente lo mismo que realizar una recolección del *heap* completo. La
-solución está entonces, una vez más, en instrumentar el *mutator* para que
+celda *vieja* es aquella que ha *sobrevivido* una cantidad *N* de
+recolecciones, mientras que el resto se consideran *jóvenes* (las celdas
+*nacen* jóvenes).  Los recolectores que utilizan este tipo de partición son
+ampliamente conocido como recolectores **generacionales**. La *hipótesis
+generacional* dice que el área de celdas jóvenes tiene una mayor probabilidad
+de ser un área de alta concentración de basura [JOLI96]_. Basándose en esto,
+los recolectores generacionales primero intentan recuperar espacio del área de
+celdas jóvenes y luego, de ser necesario, del área de celdas viejas. Es
+posible tener varias generaciones e ir subiendo de generación a generación
+a medida que es necesario. Sin embargo en general no se obtienen buenos
+resultados una vez que se superan las 3 particiones. La complejidad que trae
+este método es que para recolectar la generación joven es necesario tomar las
+referencias de la generación vieja a la joven como parte del *root set* (de
+otra forma podrían tomarse celdas como *basura* que todavía son utilizadas por
+las celdas viejas). Revisar toda la generación vieja no es una opción porque
+sería prácticamente lo mismo que realizar una recolección del *heap* completo.
+La solución está entonces, una vez más, en instrumentar el *mutator* para que

 avise al recolector cuando cambia una referencia de la generación vieja a la
 avise al recolector cuando cambia una referencia de la generación vieja a la

-joven (no es necesario monitorear las referencias en sentido inverso ya que
+joven (no es necesario vigilar las referencias en sentido inverso ya que

 cuando se recolecta la generación vieja se hace una recolección del *heap*
 completo).
 
 cuando se recolecta la generación vieja se hace una recolección del *heap*
 completo).
 

-Sin embargo, a pesar de ser este el esquema más difundido para particionar el
+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
 estático del código revisando la conectividad entre los objetos según sus
 *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
 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
+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
 de separar en distintas áreas grupos de tipos que no pueden tener referencias

-entre sí [HIRZ03]_. Este análisis hace que sea inecesario instrumentar el
+entre sí [HIRZ03]_. Este análisis hace que sea innecesario instrumentar el

 *mutator* para reportar al recolector cambios de referencias
 inter-particiones, sencillamente porque queda demostrado que no existe dicho
 *mutator* para reportar al recolector cambios de referencias
 inter-particiones, sencillamente porque queda demostrado que no existe dicho

-tipo de referencias. Esto quita una de las principale ineficiencias
+tipo de referencias. Esto quita una de las principales ineficiencias

 y complejidades del esquema generacional.
 
 
 
 .. include:: links.rst
 
 y complejidades del esquema generacional.
 
 
 
 .. include:: links.rst
 

-.. vim: set ts=3 sts=3 sw=3 et tw=78 :
+.. vim: set ts=3 sts=3 sw=3 et tw=78 spelllang=es :