.. 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:
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
-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
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*.
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
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]_::
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
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
-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.
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*.
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
<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
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
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
-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.
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
`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:
-Recolección particionada / generacional
+Recolección por particiones / generacional
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
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
-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
-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).
-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
-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
-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
-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.
projects / z.facultad / 75.00 / informe.git / blobdiff