Agregar gente que hace Software Libre a Agradecimientos

[z.facultad/75.00/informe.git] / source / dgc.rst

diff --git a/source/dgc.rst b/source/dgc.rst
index 98e260b8c05ff420ef911fe48a5a80a3690e534d..837774a2a0959bffdde09c667bd9841a43afd007 100644 (file)
--- a/source/dgc.rst
+++ b/source/dgc.rst
@@ -1,12 +1,4 @@
 
-.. Describe más detalladamente los problemas actuales del recolector de
-   basura de D, sentando las bases para el análisis de los requerimientos
-   de recolección de basura en dicho lenguaje (se explica por qué las
-   particularidades descriptas en la sección anterior complican la
-   recolección de basura y cuales son las que más molestan).
-   ESTADO: TERMINADO
-
-
 .. _dgc:
 
 Recolección de basura en D
@@ -63,7 +55,7 @@ mismas (o más) limitaciones.
 El control sobre la alineación de memoria es otra complicación sobre el
 recolector de basura, incluso aunque éste sea conservativo. Dado que tratar la
 memoria de forma conservativa byte a byte sería impracticable (tanto por la
-cantidad de falsos positivos que esto provocaría como por el impacto en el
+cantidad de *falsos positivos* que esto provocaría como por el impacto en el
 rendimiento por el exceso de posibles punteros a revisar, además de lo
 ineficiente que es operar sobre memoria no alineada), en general el recolector
 asume que el usuario nunca va a tener la única referencia a un objeto en una
@@ -130,7 +122,7 @@ una función miembro llamada *destructor*, o ``~this()`` en D_). Esto significa
 que el recolector, al encontrar que no hay más referencias a un objeto, debe
 ejecutar el destructor.
 
-La especificación dice:
+La especificación dice [DWDE]_:
 
    The garbage collector is not guaranteed to run the destructor for all
    unreferenced objects. Furthermore, the order in which the garbage collector
@@ -508,7 +500,7 @@ La función ``mark_free_lists()`` por su parte se encarga de activar el bit
 de marcado (que es iterativa y realiza varias pasadas sobre **todo** el
 *heap*, incluyendo las celdas libres) no visite las celdas libres perdiendo
 tiempo sin sentido y potencialmente manteniendo *vivas* celdas que en
-realidad son *basura* (falsos positivos)::
+realidad son *basura* (*falsos positivos*)::
 
    function mark_free_lists() is
       foreach free_list in heap
@@ -1707,14 +1699,14 @@ al lenguaje [NGD87831]_ [NGL3937]_ [NGD22968]_ [NGA15246]_ [NGD5622]_
 Finalización
 ^^^^^^^^^^^^
 El recolector actual no garantiza la finalización de objetos. En particular
-los objetos no son finalizados (es decir, no se llama a sus destructores)
-si aún alcanzables desde el *root set* cuando el programa termina. Cabe
-destacar que esto puede darse porque hay una referencia real desde el *root
-set* (en cuyo caso queda bajo el control del usuario) pero también, dado que
-el *root set* se visita de forma conservativa, se puede deber a un falso
-positivo, en cuyo caso la omisión de la finalización queda por completo fuera
-del control del usuario (y lo que es aún peor, el usuario no puede ser
-siquiera notificado de esta anomalía).
+los objetos no son finalizados (es decir, no se llama a sus destructores) si
+aún alcanzables desde el *root set* cuando el programa termina. Cabe destacar
+que esto puede darse porque hay una referencia real desde el *root set* (en
+cuyo caso queda bajo el control del usuario) pero también, dado que el *root
+set* se visita de forma conservativa, se puede deber a un *falso positivo*, en
+cuyo caso la omisión de la finalización queda por completo fuera del control
+del usuario (y lo que es aún peor, el usuario no puede ser siquiera notificado
+de esta anomalía).
 
 Si bien la especificación de D_ no requiere esta capacidad (de hecho,
 rigurosamente hablando la especificación de D_ no garantiza la finalización de
@@ -1826,12 +1818,6 @@ Marcado iterativo
 
 
 
-.. Esto sería muy similar a la sección de "Recolección de basura) pero en
-   vez de ir describiendo los algoritmos iría comentando por qué los tomo
-   o descarto
-   ESTADO: INCOMPLETO
-
-
 .. _dgc_via:
 
 Análisis de viabilidad
@@ -1937,7 +1923,7 @@ Una de las principales mejoras que pueden realizarse es hacer al recolector
 :ref:`concurrente <gc_concurrent>` y parcialmente más :ref:`preciso
 <gc_conserv>`. Estas dos mejoras solamente alcanzarían para mejorar de forma
 notable el tiempo de pausa en las recolecciones y la cantidad de memoria
-retenida debido a falsos positivos.
+retenida debido a *falsos positivos*.
 
 Más adelante veremos detalles sobre algunos de estos aspectos y sobre algunos
 algoritmos particulares que permiten hacer concurrente al recolector actual.