-.. 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
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`_.
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.
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.
.. 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
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
.. 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
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.
* 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
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.
projects / z.facultad / 75.00 / informe.git / blobdiff