]> git.llucax.com Git - z.facultad/75.00/informe.git/blobdiff - source/conclusion.rst
Mencionar ionice(1) en la metodología de pruebas
[z.facultad/75.00/informe.git] / source / conclusion.rst
index 7df0af3cd4b5328e1b57118bfd1d17c422d4bb81..f702eef2f7bb4dcea62480065270d33fb42c7106 100644 (file)
@@ -1,10 +1,4 @@
 
-.. Se presentan las conclusiones del trabajo, comparando los resultados
-   obtenidos con el punto de partida. Se mencionan puntos pendientes o
-   nuevas líneas de investigación.
-   ESTADO: TERMINADO
-
-
 .. _conclusion:
 
 Conclusión
@@ -23,11 +17,11 @@ El objetivo principal fue bajar la latencia del recolector, es decir el tiempo
 máximo de pausa real, y se pudo comprobar que, salvo en casos muy
 particulares, esto fue conseguido de manera contundente (con tiempos de pausa
 hasta 200 veces menores que el recolector original de D_). La inclusión del
-marcado concurrente demostró ser una aproximación correcta al problema.
+marcado concurrente demostró ser una forma eficaz de atacar el problema.
 
 La aceptación de la solución por parte de la comunidad también ha sido un
 objetivo importante de este trabajo, y si bien en este sentido sigue siendo un
-trabajo en curso, la recepción ha sido ampliamente positiva por parte de la
+trabajo en progreso, la recepción ha sido ampliamente positiva por parte de la
 comunidad y se espera que el resultado de este trabajo sea incorporado en el
 corto plazo tanto a `D 1.0`_ a través de Tango_, como a `D 2.0`_.
 
@@ -55,10 +49,10 @@ existen *balas de plata*, y cada programa tiene necesidades particulares en
 cuanto a recolección de basura. Por lo tanto, distintos programas pueden verse
 beneficiados o perjudicados por diferentes configuraciones. Esto hace que la
 posibilidad de configurar el recolector en tiempo de inicialización sea
-particularmente ventajoso.
+particularmente útil.
 
 Finalmente, algunas optimizaciones muy pequeñas demostraron ser también muy
-valiosas para algunos casos particulares, logrando reducciones en el tiempo
+valiosas para ciertos casos particulares, logrando reducciones en el tiempo
 total de ejecución de hasta 5 veces.
 
 
@@ -77,11 +71,12 @@ y limitaciones conocidas. A continuación se describe cada una de ellos.
   Entre las herramientas de depuración que provee el recolector, no se ha
   mencionado la posibilidad de emitir opcionalmente mensajes informativos para
   ayudar a depurar tanto problemas en el recolector como en el programa que lo
-  usa. El recolector actual tiene esa posibilidad pero es elegible en tiempo de
-  compilación. En este trabajo se agregaron las opciones en tiempo de
-  inicialización ``log_file`` y ``verbose`` con el propósito de poder elegir un
-  archivo en donde guardar los mensajes informativos y el nivel de detalle de
-  dichos mensajes respectivamente, pero finalmente nunca se implementaron.
+  usa. El recolector actual tiene esa posibilidad pero es configurable en
+  tiempo de compilación. En este trabajo se agregaron las opciones en tiempo
+  de inicialización ``log_file`` y ``verbose`` con el propósito de poder
+  elegir un archivo en donde guardar los mensajes informativos y el nivel de
+  detalle de dichos mensajes respectivamente, pero finalmente nunca se
+  implementaron.
 
 * Predicción para estimar cuando lanzar una recolección temprana.
 
@@ -230,9 +225,10 @@ y limitaciones conocidas. A continuación se describe cada una de ellos.
   precio sin obtener los beneficios. Queda pendiente analizar en más detalle
   las causas de esto y posibles optimizaciones para subsanarlo.
 
-  .. ftable:: t:con-staticsize
+  .. flt:: t:con-staticsize
+     :type: table
 
-     Aumento del tamaño de la memoria estática (bytes).
+     Aumento del tamaño de la memoria estática (bytes)
 
      ======== ======== ======== =========== ===========
      Programa TBGC     CDGC     CDGC-TBGC   CDGC/TBGC
@@ -265,7 +261,7 @@ y limitaciones conocidas. A continuación se describe cada una de ellos.
   hay necesidad de que la información de tipos sea parte del *root set*). Esto
   causa que por cada recolección, se tenga que visitar bastante más memoria y,
   lo que es probablemente peor, que aumente la probabilidad de encontrar
-  *falsos punteros*, dado que este área de memoria se marca siempre de forma
+  *falsos positivos*, dado que este área de memoria se marca siempre de forma
   conservativa.
 
   Finalmente, en el cuadro :vref:`t:con-binsize` también se puede observar un
@@ -273,9 +269,10 @@ y limitaciones conocidas. A continuación se describe cada una de ellos.
   pérdida de rendimiento, dado que puede afectar a la localidad de referencia
   del caché, por ejemplo.
 
-  .. ftable:: t:con-binsize
+  .. flt:: t:con-binsize
+     :type: table
 
-     Aumento del tamaño del binario (bytes).
+     Aumento del tamaño del binario (bytes)
 
      ======== ======== ======== =========== ===========
      Programa TBGC     CDGC     CDGC-TBGC   CDGC/TBGC
@@ -302,8 +299,8 @@ Trabajos relacionados
 
 Dado que D_ no ha penetrado en ámbitos académicos, se ha encontrado un solo
 trabajo de investigación relacionado. Sin embargo se ha encontrado otro
-trabajo que si bien no es formal, ha sido de mucha importancia para el
-desarrollo de este trabajo.
+que si bien no es formal, ha sido de mucha importancia para el desarrollo de
+esta tesis.
 
 A continuación se describen ambos.
 
@@ -324,7 +321,7 @@ A continuación se describen ambos.
 * Integración de marcado preciso del *heap* al recolector de basura
   [DBZ3463]_.
 
-  Ya citado varias veces en este trabajo, fue comenzado por David Simcha
+  Ya citado varias veces en este trabajo; fue comenzado por David Simcha
   y publicado en el sistema de seguimiento de fallas de D_ que se limita a una
   implementación a nivel biblioteca de usuario y sobre `D 2.0`_. Vincent Lang
   (mejor conocido como *wm4* en la comunidad de D_) da continuidad a este
@@ -360,7 +357,7 @@ mencionada.
   y ``dil``).
 
   Este problema no solo afecta al consumo de memoria, además genera un efecto
-  dominó por el incremento de la probabilidad de tener *falsos punteros*
+  dominó por el incremento de la probabilidad de tener *falsos positivos*
   y perjudica al tiempo total de ejecución por empeorar la localidad de
   referencia del caché y por hacer que se prolongue la recolección de basura
   por tener que marcar y barrer más memoria.