Corregir ortografía, errores de tipeo, etc.

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

diff --git a/source/gc.rst b/source/gc.rst
index 83aee26c6a5729750c15efafe793599dc58d75f4..ef01f69b4738eae95ea217c9e119325801036a75 100644 (file)
--- a/source/gc.rst
+++ b/source/gc.rst
@@ -2,7 +2,7 @@
 .. 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.
 .. 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
+   ESTADO: TERMINADO, CORREGIDO

 
 
 .. _gc:
 
 
 .. _gc:


@@ -53,7 +53,7 @@ frecuente de problemas de seguridad [BEZO06]_.
    apuntado no es el mismo tipo o porque la memoria ya ha sido liberada. Al
    ser desreferenciado, los resultados son impredecibles, el programa podría
    abortarse por una violación de segmento o podrían pasar peores cosas si el
    apuntado no es el mismo tipo o porque la memoria ya ha sido liberada. Al
    ser desreferenciado, los resultados son impredecibles, el programa podría
    abortarse por una violación de segmento o podrían pasar peores cosas si el

-   área de memoria fue realocada para almacenar otro objeto.
+   área de memoria fue re-asignada para almacenar otro objeto.

 
 La recolección de basura nació junto a Lisp_ a finales de 1950 y en los
 siguientes años estuvo asociada principalmente a lenguajes funcionales, pero
 
 La recolección de basura nació junto a Lisp_ a finales de 1950 y en los
 siguientes años estuvo asociada principalmente a lenguajes funcionales, pero


@@ -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


@@ -127,11 +127,11 @@ Registros:
    utilizar recursividad y tener un esquema simple de memoria dinámica. Sin
    embargo este esquema es muy limitado porque el orden de reserva
    y liberación de memoria tiene que estar bien establecido. Una celda
    utilizar recursividad y tener un esquema simple de memoria dinámica. Sin
    embargo este esquema es muy limitado porque el orden de reserva
    y liberación de memoria tiene que estar bien establecido. Una celda

-   [#gccelda]_ alocada antes que otra nunca puede ser liberada antes que
+   [#gccelda]_ asignada antes que otra nunca puede ser liberada antes que

    aquella.
 
    .. [#gccelda] En general en la literatura se nombra a una porción de
    aquella.
 
    .. [#gccelda] En general en la literatura se nombra a una porción de

-      memoria alocada individualmente *celda*, *nodo* u *objeto*
+      memoria asignada individualmente *celda*, *nodo* u *objeto*

       indistintamente. En este trabajo se utilizará la misma nomenclatura
       (haciendo mención explícita cuando alguno de estos términos se refiera
       a otra cosa, como al nodo de una lista o a un objeto en el sentido de
       indistintamente. En este trabajo se utilizará la misma nomenclatura
       (haciendo mención explícita cuando alguno de estos términos se refiera
       a otra cosa, como al nodo de una lista o a un objeto en el sentido de


@@ -181,11 +181,11 @@ 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í. 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*.

 
 
 
 
 
 


@@ -257,6 +257,8 @@ Esto es, efectivamente, una partición del *heap* (ver figura
 
 .. fig:: fig:gc-heap-parts
 
 
 .. fig:: fig:gc-heap-parts
 

+   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*.
 


@@ -320,7 +322,7 @@ 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
 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
+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
 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


@@ -328,7 +330,7 @@ uno u otro método para lograr una mejor localidad de referencia.
    completamente arbitrarios, ya que cualquier *vértice interior* puede ser un
    *vértice terminal*.
 
    completamente arbitrarios, ya que cualquier *vértice interior* puede ser un
    *vértice terminal*.
 

-Un algoritmo simple (recursivo) de marcado *primero a lo alto*  puede ser el
+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]_::
 
 siguiente (asumiendo que partimos con todos los vértices sin marcar)
 [#gcpseudo]_::
 


@@ -596,8 +598,8 @@ 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
 se punta de gris. Luego se van obteniendo celdas del conjunto de las grises
 
 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


@@ -816,14 +818,14 @@ inicial* es el mismo que el *vértice final*.
 Cuando esto sucede, las celdas que participan del ciclo tienen siempre su
 contador mayor que 0, sin embargo puede no haber ningún elemento del *root
 set* que apunte a una celda dentro del ciclo, por lo tanto el ciclo es
 Cuando esto sucede, las celdas que participan del ciclo tienen siempre su
 contador mayor que 0, sin embargo puede no haber ningún elemento del *root
 set* que apunte a una celda dentro del ciclo, por lo tanto el ciclo es

-*basura* (al igual que cualquier otra celda que sea referenciada por el ciclo
-pero que no tenga otras referencias externas) y sin embargo los contadores no
-son 0. Los ciclos, por lo tanto, *rompen* la invariante del conteo de
-referencia.
+*basura* (al igual que cualquier otra celda 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
+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.
 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.


@@ -845,7 +847,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,6 +860,8 @@ conduce al decremento del contador de ``h2`` y ``h3`` que permanecen en el
 
 .. fig:: fig:gc-rc-rm-1
 
 
 .. fig:: fig:gc-rc-rm-1
 

+   Ejemplo de conteo de referencias: eliminación de una referencia (parte 1).
+

    Eliminación de la referencia ``r0`` :math:`\to` ``h1`` (parte 1).
 
    .. subfig::
    Eliminación de la referencia ``r0`` :math:`\to` ``h1`` (parte 1).
 
    .. subfig::


@@ -1012,6 +1016,8 @@ conduce al decremento del contador de ``h2`` y ``h3`` que permanecen en el
 .. fig:: fig:gc-rc-rm-2
    :padding: 0.5
 
 .. fig:: fig:gc-rc-rm-2
    :padding: 0.5
 

+   Ejemplo de conteo de referencias: eliminación de una referencia (parte 2).
+

    Eliminación de la referencia ``r0`` :math:`\to` ``h1`` (parte 2).
 
    .. subfig::
    Eliminación de la referencia ``r0`` :math:`\to` ``h1`` (parte 2).
 
    .. subfig::


@@ -1129,6 +1135,8 @@ contador de ``h2`` que queda en 0, transformándose en *basura* (ver figura
 
 .. fig:: fig:gc-rc-up-1
 
 
 .. fig:: fig:gc-rc-up-1
 

+   Ejemplo de conteo de referencias: actualización de una referencia (parte 1).
+

    Cambio en la referencia ``h2.l`` :math:`\to` ``h2`` a ``h2.l`` :math:`\to`
    ``h5`` (parte 1).
 
    Cambio en la referencia ``h2.l`` :math:`\to` ``h2`` a ``h2.l`` :math:`\to`
    ``h5`` (parte 1).
 


@@ -1301,6 +1309,8 @@ de actualizar la referencia ``h3.l`` para que apunte a ``h5`` (ver figura
 
 .. fig:: fig:gc-rc-up-2
 
 
 .. fig:: fig:gc-rc-up-2
 

+   Ejemplo de conteo de referencias: actualización de una referencia (parte 2).
+

    Cambio en la referencia ``h2.l`` :math:`\to` ``h2`` a ``h2.l`` :math:`\to`
    ``h5`` (parte 2).
 
    Cambio en la referencia ``h2.l`` :math:`\to` ``h2`` a ``h2.l`` :math:`\to`
    ``h5`` (parte 2).
 


@@ -1480,6 +1490,8 @@ pueden ser recicladas y su memoria es perdida (ver figura
 .. fig:: fig:gc-rc-cycle
    :padding: 0.5
 
 .. fig:: fig:gc-rc-cycle
    :padding: 0.5
 

+   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).
 


@@ -1671,10 +1683,20 @@ Copia de semi-espacio
 
 Este algoritmo consiste en hacer una partición del *heap* en 2 mitades
 o *semi-espacios*, llamados usualmente *Fromspace* y *Tospace*. El primero se
 
 Este algoritmo consiste en hacer una partición del *heap* en 2 mitades
 o *semi-espacios*, llamados usualmente *Fromspace* y *Tospace*. El primero se

-utiliza para alocar nuevas celdas de forma lineal, asumiendo un *heap*
+utiliza para asignar nuevas celdas de forma lineal, asumiendo un *heap*

 contiguo, incrementando un puntero (ver figura :vref:`fig:gc-copy`).  Esto se
 conoce como *pointer bump allocation* y es, probablemente, la forma más
 contiguo, incrementando un puntero (ver figura :vref:`fig:gc-copy`).  Esto se
 conoce como *pointer bump allocation* y es, probablemente, la forma más

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

 
 .. fig:: fig:gc-copy
 
 
 .. fig:: fig:gc-copy
 


@@ -1707,10 +1729,10 @@ La segunda mitad (*Tospace*) permanece inutilizada hasta que se agota el
 espacio en el *Fromspace*; en ese momento comienza el proceso de recolección
 de basura que consiste en recorrer el grafo de conectividad, copiando las
 celdas *vivas* del *Fromspace* al *Tospace* de manera contigua, como si
 espacio en el *Fromspace*; en ese momento comienza el proceso de recolección
 de basura que consiste en recorrer el grafo de conectividad, copiando las
 celdas *vivas* del *Fromspace* al *Tospace* de manera contigua, como si

-estuvieran alocando por primera vez. Como la posición en memoria de las celdas
-cambia al ser movidas, es necesario actualizar la dirección de memoria de
-todas las celdas *vivas*. Para esto se almacena una dirección de memoria de
-redirección, *forwarding address*, en las celdas que mueven. La *forwarding
+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
+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


@@ -1723,7 +1745,7 @@ viejo *Fromspace* es *basura* por definición, por lo que se convierte el
 A continuación se presenta una implementación sencilla de los servicios
 provistos por este tipo de recolectores. Cabe destacar que este tipo de
 recolectores deben estar íntimamente relacionados con el *low level
 A continuación se presenta una implementación sencilla de los servicios
 provistos por este tipo de recolectores. Cabe destacar que este tipo de
 recolectores deben estar íntimamente relacionados con el *low level

-allocator*, ya que la organización del *heap* y la forma de alocar memoria es
+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``
 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``


@@ -1732,7 +1754,7 @@ 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
 comienza la memoria libre). También vale aclarar que este algoritmo soporta
 inherentemente celdas de tamaño variable, por lo que los servicios ``alloc()``
 y ``new()`` [#gccopynew]_ reciben como parámetro el tamaño de la celda

-a alocar::
+a asignar::

 
    function alloc(size) is
       if free + size > fromspace + spacesize
 
    function alloc(size) is
       if free + size > fromspace + spacesize


@@ -1781,7 +1803,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


@@ -2097,7 +2119,7 @@ con el *mutator* en cada actualización del grafo de conectividad (exceptuando
 algunos :ref:`recolectores incrementales <gc_inc>` que a veces necesitan
 instrumentar el *mutator* pero no para mantener el estado del grafo de
 conectividad completo). La recolección se dispara usualmente cuando el
 algunos :ref:`recolectores incrementales <gc_inc>` que a veces necesitan
 instrumentar el *mutator* pero no para mantener el estado del grafo de
 conectividad completo). La recolección se dispara usualmente cuando el

-*mutator* requiere alocar memoria pero no hay más memoria libre conocida
+*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*.
 
 disponible y el recolector se encarga de generar la información de
 conectividad desde cero para determinar qué celdas son *basura*.
 


@@ -2128,7 +2150,7 @@ De los `algoritmos clásicos`_ el único que es incremental en su forma más
 básica es el :ref:`conteo de referencias <gc_rc>`. Otros recolectores pueden
 hacerse incrementales de diversas maneras, pero en general consta de hacer
 parte del trabajo de escanear el grafo de conectividad cada vez que el
 básica es el :ref:`conteo de referencias <gc_rc>`. Otros recolectores pueden
 hacerse incrementales de diversas maneras, pero en general consta de hacer
 parte del trabajo de escanear el grafo de conectividad cada vez que el

-*mutator* aloca memoria. En general para hacer esto es también necesario
+*mutator* asigna memoria. En general para hacer esto es también necesario

 instrumentar al *mutator* de forma tal que informe al recolector cada vez que
 cambia el grafo de conectividad, para que éste pueda marcar al sub-grafo
 afectado por el cambio como *desactualizado* y así re-escanearlo nuevamente en
 instrumentar al *mutator* de forma tal que informe al recolector cada vez que
 cambia el grafo de conectividad, para que éste pueda marcar al sub-grafo
 afectado por el cambio como *desactualizado* y así re-escanearlo nuevamente en


@@ -2137,7 +2159,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


@@ -2274,26 +2296,27 @@ en una lista de libres. Al solicitarse una nueva celda simplemente se la
 desenlaza de la lista de libres. Por otro lado, cuando el recolector detecta
 una celda *muerta*, la vuelve a enlazar en la lista de libres. Este es un
 esquema simple pero con limitaciones, entre las principales, el costo de
 desenlaza de la lista de libres. Por otro lado, cuando el recolector detecta
 una celda *muerta*, la vuelve a enlazar en la lista de libres. Este es un
 esquema simple pero con limitaciones, entre las principales, el costo de

-alocar puede ser alto si hay muchos tamaños distintos de celda y soportar
+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
 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*
 
 Otro forma de organizar el *heap* es utilizándolo como una especie de *stack*

-en el cual para alocar simplemente se incrementa un puntero. Este esquema es
+en el cual para asignar simplemente se incrementa un puntero. Este esquema es

 simple y eficiente, si el recolector puede mover celdas (ver
 simple y eficiente, si el recolector puede mover celdas (ver

-:ref:`gc_moving`); de otra manera alocar puede ser muy costoso si hay que
+:ref:`gc_moving`); de otra manera asignar puede ser muy costoso si hay que

 buscar un *hueco* en el heap (es decir, deja de reducirse a incrementar un
 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.
 Dentro de una región se utiliza un esquema de *pointer bump allocation* pero
 las regiones en sí se administran como una lista de libres (como por ejemplo
 [BLAC08]_). Otra variación (más común) de este esquema son los *two level
 
 Sin embargo, entre estos dos extremos, hay todo tipo de híbridos. Existen
 recolectores basados en *regiones*, que se encuentran en un punto intermedio.
 Dentro de una región se utiliza un esquema de *pointer bump allocation* pero
 las regiones en sí se administran como una lista de libres (como por ejemplo
 [BLAC08]_). Otra variación (más común) de este esquema son los *two level

-allocators* que alocan páginas completas (similar a las regiones) y dentro de
-cada página se alocan las celdas. Ambas, páginas y celdas, se administran como
-listas de libres (ejemplos que utilizan este esquema son [BOEHWD]_ y el
+allocators* que asignan páginas completas (similar a las regiones) y dentro de
+cada página se asignan las celdas. Ambas, páginas y celdas, se administran
+como listas de libres (ejemplos que utilizan este esquema son [BOEHWD]_ y el

 :ref:`recolector actual de D <dgc_actual>`).
 
 
 :ref:`recolector actual de D <dgc_actual>`).
 
 


@@ -2307,7 +2330,7 @@ Otra característica muy importante del recolector de basura es si mueve las
 celdas o no. En general el movimiento de celdas viene de la mano del esquema
 de :ref:`pointer bump allocation <gc_free_list>`, ya que *compacta* todas las
 celdas *vivas* al comienzo del *heap* luego de una recolección, permitiendo
 celdas o no. En general el movimiento de celdas viene de la mano del esquema
 de :ref:`pointer bump allocation <gc_free_list>`, ya que *compacta* todas las
 celdas *vivas* al comienzo del *heap* luego de una recolección, permitiendo

-este esquema para alocar nuevas celdas, pero puede utilizarse en esquemas
+este esquema para asignar nuevas celdas, pero puede utilizarse en esquemas

 híbridos como recolectores basados en *regiones* (por ejemplo [BLAC08]_).
 
 Además los recolectores con movimiento de celdas deben ser :ref:`precisos
 híbridos como recolectores basados en *regiones* (por ejemplo [BLAC08]_).
 
 Además los recolectores con movimiento de celdas deben ser :ref:`precisos


@@ -2370,7 +2393,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


@@ -2383,19 +2406,20 @@ 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
+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


@@ -2421,40 +2445,40 @@ 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.
 
 
 y complejidades del esquema generacional.