X-Git-Url: https://git.llucax.com/z.facultad/75.00/informe.git/blobdiff_plain/21f5e573dc375b4f716798b3aeec945a62e8891d..be3f0d3da074ebb18d99031d965e2b00e251d071:/source/gc.rst?ds=inline diff --git a/source/gc.rst b/source/gc.rst index 06ed07e..1998a31 100644 --- a/source/gc.rst +++ b/source/gc.rst @@ -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 @@ -183,10 +167,9 @@ 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 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. @@ -225,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`. @@ -318,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 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) @@ -632,9 +615,9 @@ vacíos):: 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*. @@ -703,7 +686,8 @@ Y los servicios básicos proporcionados por el recolector son los siguientes: referencias `. 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()` indica al recolector que debe hacer un análisis del grafo de conectividad @@ -722,7 +706,7 @@ aunque en ciertas circunstancias pueden ser utilizados por el usuario también. 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. @@ -815,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 -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: @@ -1141,7 +1123,7 @@ contador de ``h2`` que queda en 0, transformándose en *basura* (ver figura 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:: @@ -1199,7 +1181,7 @@ contador de ``h2`` que queda en 0, transformándose en *basura* (ver figura .. subfig:: - 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 @@ -1315,7 +1297,7 @@ de actualizar la referencia ``h3.l`` para que apunte a ``h5`` (ver figura 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:: @@ -2257,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. -¿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