X-Git-Url: https://git.llucax.com/z.facultad/75.00/informe.git/blobdiff_plain/93304243d72347314f0d9c402a0632ab50550016..HEAD:/source/conclusion.rst?ds=inline diff --git a/source/conclusion.rst b/source/conclusion.rst index 7df0af3..f702eef 100644 --- a/source/conclusion.rst +++ b/source/conclusion.rst @@ -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.