]> git.llucax.com Git - z.facultad/75.00/informe.git/blobdiff - source/gc.rst
Agregar estilo para imprimir
[z.facultad/75.00/informe.git] / source / gc.rst
index 585baa105b4d721cb510cfc47cdc57423c7fc4df..ae398cf1ba379d29ab96dd93ba1daedac8276cf1 100644 (file)
@@ -1,10 +1,4 @@
 
-.. 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
-
-
 .. _gc:
 
 Recolección de basura
@@ -159,9 +153,9 @@ está almacenada en otra celda *viva* del *heap*.
 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
-nuevamente. Esto no es siempre cierto y los falsos positivos que esto produce
-se conoce como un tipo de pérdida de memoria (que es posible incluso al
-utilizar un recolector de basura) llamada pérdida de memoria *lógica*. Esto
+nuevamente. Esto no es siempre cierto y los *falsos positivos* que esto
+produce se conoce como un tipo de pérdida de memoria (que es posible incluso
+al utilizar un recolector de basura) llamada pérdida de memoria *lógica*. Esto
 puede no ser evitable (incluso cuando el programador no cometa errores) en
 lenguajes de programación que requieran un recolector de basura conservativo.
 
@@ -241,7 +235,7 @@ Más formalmente, Definimos:
 
       Basura = V - Live \thickspace set
 
-Esto es, efectivamente, una partición del *heap* (ver figura
+El *Live set* y la *Basura* conforman una partición del *heap* (ver figura
 :vref:`fig:gc-heap-parts`).
 
 
@@ -2333,17 +2327,17 @@ y barrido <gc_mark_sweep>` no lo hacen. Además hay otro algoritmo bastante
 básico que mueve celdas, el **marcado y compactado**. Éste no tiene
 2 semi-espacios, directamente mueve las celdas compactándolas al comienzo del
 *heap*. El algoritmo es un poco más complejo que la :ref:`copia de
-semi-espacios <gc_copy>` pero suele poder proveer una mayor localidad de
-referencia y *desperdicia* un semi-espacio que está inutilizado salgo en el
-momento de la recolección. Por ejemplo para Mono_, que antes usaba un
-recolector conservativo sin movimiento ([BOEHWD]_) se está implementando un
-recolector de este tipo [MOLAWE]_ [MOLA06]_.
+semi-espacios <gc_copy>` pero suele proveer una mayor localidad de referencia
+y no *desperdicia* un semi-espacio que está inutilizado salvo en el momento de
+la recolección. Por ejemplo para Mono_, que antes usaba un recolector
+conservativo sin movimiento ([BOEHWD]_) se está implementando un recolector de
+este tipo [MOLAWE]_ [MOLA06]_.
 
 
 
 .. _gc_conserv:
 
-Recolectores conservativos vs precisos
+Recolectores conservativos versus precisos
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Los recolectores *conservativos* son aquellos que tienen la capacidad de poder
@@ -2354,8 +2348,8 @@ o no. Esto trae una variada cantidad de problemas, como retención de celdas
 que en realidad son *basura* simplemente porque hay algún dato que coincide
 con la dirección de memoria en la que está almacenada esa celda *basura*
 [#gcflasepos]_. Además los recolectores puramente conservativos no puede mover
-celdas (ver :ref:`gc_moving`), porque no pueden arriesgarse a actualizar los
-punteros por el riesgo que existe de que sean falsos positivos.
+celdas (ver :ref:`gc_moving`), dado que no pueden actualizar los supuestos
+punteros por la posibilidad de que sean *falsos positivos*.
 
 .. [#gcflasepos] Esto es lo que se conoce como un *falso positivo*, algo que
    aparenta ser un puntero pero en realidad no lo es.
@@ -2452,7 +2446,7 @@ completo).
 
 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
+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
 de separar en distintas áreas grupos de tipos que no pueden tener referencias