X-Git-Url: https://git.llucax.com/z.facultad/75.00/informe.git/blobdiff_plain/29bffac4720cd850418640db1963ec23690710c9..409ef528d2b45bdcbcd6868b3d0f82c1edf8e748:/source/gc.rst?ds=sidebyside diff --git a/source/gc.rst b/source/gc.rst index c08c979..ff79b4f 100644 --- 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. - ESTADO: TERMINADO, CORREGIDO + ESTADO: TERMINADO .. _gc: @@ -156,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*. -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 @@ -224,6 +208,11 @@ Más formalmente, Definimos: \exists (v_i \to v_{i+1}) \in A \right\rbrace + Un camino cuyos *vértices terminales* coinciden, es decir :math:`v_1 + = v_N`, es denominado **Ciclo**. Cabe notar que los *vértices terminales* + de un ciclo son completamente arbitrarios, ya que cualquier *vértice + interior* puede ser un *vértice terminal*. + *Conexión* decimos que :math:`M` está *conectado* a :math:`N` si y sólo si existe un camino de :math:`M` a :math:`N`. @@ -255,9 +244,9 @@ Esto es, efectivamente, una partición del *heap* (ver figura :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*. @@ -317,18 +306,13 @@ Esto es, efectivamente, una partición del *heap* (ver figura Al proceso de visitar los vértices *conectados* desde el *root set* se lo denomina *marcado*, *fase de marcado* o *mark phase* en inglés, debido a que -es necesario marcar los vértices para evitar visitar dos 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) @@ -337,7 +321,7 @@ 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 @@ -365,11 +349,11 @@ con el marcado del grafo completo, dejando sin marcar solamente las celdas *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. @@ -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``. @@ -436,7 +420,7 @@ con el marcado del grafo completo, dejando sin marcar solamente las celdas } - .. subfig:: + .. subflt:: 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. @@ -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. @@ -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 @@ -624,7 +608,7 @@ vacíos):: 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) @@ -815,9 +799,7 @@ 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 -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 suceder que ningún elemento del *root @@ -839,7 +821,7 @@ 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: @@ -862,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`). -.. 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). - .. subfig:: + .. subflt:: Estado inicial del grafo de conectividad. @@ -915,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``. @@ -963,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``. @@ -1017,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 - 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). - .. subfig:: + .. subflt:: Se decrementa el contador de ``h2`` pero no queda en 0 (permanece en el *live set*). @@ -1077,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*. @@ -1137,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`). -.. 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 ``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``. @@ -1197,7 +1179,7 @@ contador de ``h2`` que queda en 0, transformándose en *basura* (ver figura } - .. subfig:: + .. subflt:: Luego se procede a visitar la antigua referencia de ``h3.l`` (``h2``). @@ -1250,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. @@ -1311,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`). -.. 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 ``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``. @@ -1372,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. @@ -1425,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``. @@ -1491,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`). -.. 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. + 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``. @@ -1553,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. @@ -1702,9 +1684,9 @@ sus *low level allocators*). sucede y se acumulan muchos *huecos* se dice que la memoria está *fragmentada*. -.. fig:: fig:gc-copy +.. flt:: fig:gc-copy - Estructura del *heap* de un recolector con copia de semi-espacios. + Estructura del *heap* de un recolector con copia de semi-espacios .. aafig:: :aspect: 70 @@ -1836,11 +1818,11 @@ apunta a ``h3``, por lo tanto ésta es movida al *Tospace* primero, dejando una *forwarding address* a la nueva ubicación (ver figura :vref:`fig:gc-copy-ex-1`). -.. 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. @@ -1871,7 +1853,7 @@ apunta a ``h3``, por lo tanto ésta es movida al *Tospace* primero, dejando una | "Tospace" | +--------------------------------------------------+ - .. subfig:: + .. subflt:: Se sigue la referencia del *root set*, copiando ``h3`` al *Tospace* y dejando una *forwarding address*. @@ -1913,11 +1895,11 @@ sido visitada, solamente se actualiza la referencia apuntando a la nueva ubicación de ``h2`` pero no se vuelve a copiar la celda (ver figura :vref:`fig:gc-copy-ex-2`). -.. 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*. @@ -1948,7 +1930,7 @@ ubicación de ``h2`` pero no se vuelve a copiar la celda (ver figura | "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 @@ -1987,11 +1969,11 @@ semi-espacios y se actualiza la referencia del *root set* para que apunte a la nueva ubicación de ``h3``, como se muestra en la figura :vref:`fig:gc-copy-ex-3`. -.. 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*. @@ -2022,7 +2004,7 @@ nueva ubicación de ``h3``, como se muestra en la figura | "Tospace" \------/ | +--------------------------------------------------+ - .. subfig:: + .. subflt:: Se finaliza la recolección, se intercambian los roles de los semi-espacios y se actualiza la referencia del *root set*. @@ -2183,12 +2165,12 @@ clase de colectores que si bien son *stop-the-world*, utilizan todos los hilos disponibles para realizar la recolección (ver figura :vref:`fig:gc-concurrent`). -.. fig:: fig:gc-concurrent +.. flt:: fig:gc-concurrent Distintos tipos de recolectores según el comportamiento en ambientes - multi-hilo. + multi-hilo - .. subfig:: + .. subflt:: *Stop-the-world*. @@ -2207,7 +2189,7 @@ disponibles para realizar la recolección (ver figura | HH Mutator ZZ Inactivo XX Recolector | |___________________________________________________________________| - .. subfig:: + .. subflt:: Paralelo. @@ -2226,7 +2208,7 @@ disponibles para realizar la recolección (ver figura | HH Mutator ZZ Inactivo XX Recolector | |___________________________________________________________________| - .. subfig:: + .. subflt:: Concurrente. @@ -2424,11 +2406,11 @@ haya. Entonces, si el recolector tiene algún mecanismo para identificar zonas de alta concentración de *basura* puede hacer la recolección solo en ese área -donde el trabajo va a ser mejor recompensado (ver :vref:`fig:gc-part`). +donde el trabajo va a ser mejor recompensado (ver figura :vref:`fig:gc-part`). -.. fig:: fig:gc-part +.. flt:: fig:gc-part - Concentración de basura en distintas particiones del *heap*. + Concentración de basura en distintas particiones del *heap* .. aafig:: :scale: 110