.. Introducción a la importancia de la recolección de basura y sus
principales técnicas, con sus ventajas y desventajas. También se da
un breve recorrido sobre el estado del arte.
- ESTADO: TERMINADO, CORREGIDO
+ ESTADO: TERMINADO
.. _gc:
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
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
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
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
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
Por último, siendo que el recolector de basura es parte del programa de forma
indirecta, es común ver en la literatura que se diferencia entre dos partes
-del programa, el recolector de basura y el programa en sí. Dado que para el
-recolector de basura, lo único que interesa conocer del programa en sí son los
-cambios al grafo de conectividad de las celdas, normalmente se lo llama
-*mutator*.
+del programa, el recolector de basura y el programa en sí. A la primera se la
+suele denominar simplemente *recolector* y a la segunda *mutator*, dado que es
+la única que modifica (o *muta*) el grafo de conectividad.
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*).
\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`.
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.
\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*.
:vref:`fig:gc-heap-parts`).
-.. fig:: fig:gc-heap-parts
+.. flt:: fig:gc-heap-parts
Distintas partes de la memoria *heap*.
Al proceso de visitar los vértices *conectados* desde el *root set* se lo
denomina *marcado*, *fase de marcado* o *mark phase* en inglés, debido a que
-es necesario marcar los vértices para evitar visitar 2 veces el mismo nodo en
-casos de que el grafo contenga ciclos [#gccycle]_. De forma similar a la
-búsqueda, que puede realizarse *primero a lo ancho* (*breadth-first*)
-o *primero a lo alto* (*depth-first*) del grafo, el marcado de un grafo
-también puede realizarse de ambas maneras. Cada una podrá o no tener efectos
-en el rendimiento, en particular dependiendo de la aplicación puede convenir
-uno u otro método para lograr una mejor localidad de referencia.
-
-.. [#gccycle] Un ciclo es un camino donde el *vértice inicial* es el mismo
- que el *vértice final*. Por lo tanto, los *vértices terminales* son
- completamente arbitrarios, ya que cualquier *vértice interior* puede ser un
- *vértice terminal*.
+es necesario marcar los vértices para evitar visitar dos veces el mismo nodo
+en casos en los que el grafo contenga ciclos. De forma similar a la búsqueda,
+que puede realizarse *primero a lo ancho* (*breadth-first*) o *primero a lo
+alto* (*depth-first*) del grafo, el marcado de un grafo también puede
+realizarse de ambas maneras. Cada una podrá o no tener efectos en el
+rendimiento, en particular dependiendo de la aplicación puede convenir uno
+u otro método para lograr una mejor localidad de referencia.
Un algoritmo simple (recursivo) de marcado *primero a lo alto* puede ser el
siguiente (asumiendo que partimos con todos los vértices sin marcar)
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
*basura* (en blanco).
-.. fig:: fig:gc-mark-1
+.. flt:: fig:gc-mark-1
Ejemplo de marcado del grafo de conectividad (parte 1).
- .. subfig::
+ .. subflt::
Se comienza a marcar el grafo por la raíz r0.
}
- .. subfig::
+ .. subflt::
Luego de marcar el nodo ``h1``, se procede al ``h2``.
}
- .. subfig::
+ .. subflt::
Luego sigue el nodo h5.
}
-.. fig:: fig:gc-mark-2
+.. flt:: fig:gc-mark-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.
}
- .. 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.
}
- .. 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
while not gray_set.empty()
v = gray_set.pop()
black_set.add(v)
- for (src, dst) in v.edges
+ foreach (src, dst) in v.edges
if dst in white_set
white_set.remove(dst)
gray_set.add(dst)
Si bien este algoritmo no es recursivo, tiene un requerimiento de espacio
:math:`O(\lvert Live \thickspace set \rvert)`. Un ejemplo donde se aprecia
-esto a simple vista es cuando el *live set* resulta una lista simplemente
-enlazada, en cuyo caso el :math:`gray_set` deberá almacenar todos los nodos
-del *live set*.
+esto a simple vista es cuando el *Live set* resulta una lista simplemente
+enlazada, en cuyo caso el *gray_set* deberá almacenar todos los nodos del
+*Live set*.
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
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:
-:math:`new() \to cell`:
+:math:`new() \to cell`
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
: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
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.
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.
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
-contador mayor que 0, sin embargo puede no haber ningún elemento del *root
-set* que apunte a una celda dentro del ciclo, por lo tanto el ciclo es
-*basura* (al igual que cualquier otra celda para la cual hayan referencias
-desde el ciclo pero que no tenga otras referencias externas) y sin embargo los
+contador mayor que 0, sin embargo puede suceder que ningún elemento del *root
+set* apunte a una celda dentro del ciclo, por lo tanto el ciclo es *basura*
+(al igual que cualquier otra celda para la cual hayan referencias desde el
+ciclo pero que no tenga otras referencias externas) y sin embargo los
contadores no son 0. Los ciclos, por lo tanto, violan la invariante del conteo
de referencia.
Hay formas de solucionar esto, pero siempre recaen en un esquema que va por
fuera del conteo de referencias puro. En general los métodos para solucionar
esto son variados y van desde realizar un marcado del sub-grafo para detectar
-nodos hasta tener otro recolector completo de *emergencia*, pasando por tratar
-los ciclos como un todo contar las referencias al ciclo completo en vez de
-a cada celda en particular.
+ciclos y liberarlos hasta tener otro recolector completo de *emergencia*;
+pasando por tratar los ciclos como un todo para contar las referencias al
+ciclo completo en vez de a cada celda en particular.
Incluso con este problema, el conteo de referencia sin ningún tipo de solución
en cuanto a la detección y recolección de ciclos fue utilizado en muchos
lenguajes de programación sin que su necesidad sea tan evidente. Por ejemplo
Python_ agregó recolección de ciclos en la versión 2.0 [NAS00]_ (liberada en
octubre de 2000) y PHP_ recién agrega detección de ciclos en la versión 5.3
-(todavía no liberada al momento de escribir este documento) [PHP081]_.
+[PHP530]_.
.. _gc_rc_example:
*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).
Eliminación de la referencia ``r0`` :math:`\to` ``h1`` (parte 1).
- .. subfig::
+ .. subflt::
Estado inicial del grafo de conectividad.
}
- .. subfig::
+ .. subflt::
Al ejecutarse ``update(r0, null)``, se comienza por visitar la celda
``h1``.
}
- .. subfig::
+ .. subflt::
Se decrementa el contador de ``h1`` quedando en 0 (pasa a ser *basura*).
Se elimina primero ``h1.l`` y luego ``h1.r``.
}
-.. fig:: fig:gc-rc-rm-2
+.. flt:: 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::
+ .. subflt::
Se decrementa el contador de ``h2`` pero no queda en 0 (permanece en el
*live set*).
}
- .. subfig::
+ .. subflt::
El contador de ``h3`` tampoco queda en 0, sigue en el *live set*.
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).
- 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).
- .. subfig::
+ .. subflt::
Comienza ``update(h3.l, h5)``, se incrementa el contador de ``h5``.
}
- .. 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
}
- .. subfig::
+ .. subflt::
Se decrementa el contador de ``h2`` y queda en 0 (pasa a ser *basura*).
Se eliminan las referencias a las hijas.
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).
- 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).
- .. subfig::
+ .. subflt::
Se decrementa el contador de ``h4`` quedando en 0, pasa a ser *basura*.
Se continúa con ``h5``.
}
- .. subfig::
+ .. subflt::
Se decrementa el contador de ``h5`` pero sigue siendo mayor que 0.
}
- .. subfig::
+ .. subflt::
Se termina por actualizar la referencia de ``h3.l`` para que apunte
a ``h5``.
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
Ejemplo de conteo de referencias: pérdida de memoria debido a un ciclo.
Eliminación de la referencia ``r1`` :math:`\to` ``h3`` (pérdida de memoria
debido a un ciclo).
- .. subfig::
+ .. subflt::
El ejecutarse ``update(r1, null)`` se visita la celda ``h3``.
}
- .. subfig::
+ .. subflt::
Se decrementa el contador de ``h3`` pero sigue siendo mayor que 0 por el
ciclo.
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.
*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).
- .. subfig::
+ .. subflt::
Estructura inicial del *heap*. El *Fromspace* está complete y se inicial
la recolección.
| "Tospace" |
+--------------------------------------------------+
- .. subfig::
+ .. subflt::
Se sigue la referencia del *root set*, copiando ``h3`` al *Tospace*
y dejando una *forwarding address*.
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).
- .. subfig::
+ .. subflt::
Se sigue :math:`h3 \to h2`, copiando ``h2`` al *Tospace* y dejando una
*forwarding address*.
| "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
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).
- .. subfig::
+ .. subflt::
Se sigue :math:`h1 \to h4` copiando `h4`` al *Tospace* y dejando una
*forwarding address*.
| "Tospace" \------/ |
+--------------------------------------------------+
- .. subfig::
+ .. subflt::
Se finaliza la recolección, se intercambian los roles de los
semi-espacios y se actualiza la referencia del *root set*.
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
multi-hilo.
- .. subfig::
+ .. subflt::
*Stop-the-world*.
| HH Mutator ZZ Inactivo XX Recolector |
|___________________________________________________________________|
- .. subfig::
+ .. subflt::
Paralelo.
| HH Mutator ZZ Inactivo XX Recolector |
|___________________________________________________________________|
- .. subfig::
+ .. subflt::
Concurrente.
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
-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
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*.
projects / z.facultad / 75.00 / informe.git / blobdiff