X-Git-Url: https://git.llucax.com/z.facultad/75.00/informe.git/blobdiff_plain/b0956c037ae52da777b06705157486067755ec2c..447cc68bb907ff0153fcdd794750bd147977412f:/source/conclusion.rst diff --git a/source/conclusion.rst b/source/conclusion.rst index 2de8ffd..7264b44 100644 --- a/source/conclusion.rst +++ b/source/conclusion.rst @@ -5,7 +5,7 @@ ESTADO: SIN EMPEZAR -.. _ref_conclusion: +.. _conclusion: Conclusión ============================================================================ @@ -13,12 +13,33 @@ Conclusión TODO +Puntos pendientes +---------------------------------------------------------------------------- + +TODO + +* Opciones log_file/verbose +* Lazy sweeping. +* Concurrent sweeping (lanzar fase de sweep en un thread que no pertenezca al + mutator). +* Continuous collection (lanzar un thread que esté haciendo fullcollect() en + un loop). Lo bueno es que el sweep podría correr en ese thread, bajando aún + más el tiempo máximo de pausa (aunque esto se puede hacer más allá de hacer + continuous collection, ver "concurrent sweeping"), lo malo es que tal vez se + estaría recolectando demasiado sin ninguna ganancia substancial. +* Medir mejor cuando lanzar una recolección cuando se usa early collection + (por ejemplo medir la tasa de alocación y el tiempo de recolección y así + hallar el momento ideal para lanzar la recolección). +* Emprolijar todavía más el código (o reescribirlo). + Trabajos relacionados ---------------------------------------------------------------------------- TODO +* Diamond: + http://thecybershadow.net/d/Memory_Management_in_the_D_Programming_Language.pdf Trabajos futuros @@ -26,6 +47,17 @@ Trabajos futuros TODO +* Cambiar el layout de memoria (mostrar lo encontrado en el post). Se podría + usar un tamaño de bloque por cada tipo de dato (y por lo tanto una lista de + libres por cada tipo de dato). Esto podría ahorrar muchos bits (mark, + freebits, scan, etc.), el puntero al pointer mask se guardaría una sola vez, + no hay ningún desperdicio de espacio salvo algún padding, pero podrían haber + esquemas donde ni siquiera (si siempre se alocan tantas páginas como sean + necesarias para evitar el padding para un tamaño de bloque). Un tipo de dato + NO_SCAN no alocaría directamente bits de noscan, mark y scan. Se podría + tratar de forma especial a strings. +* Hacer preciso el static data por el tema de los TypeInfo's que ocupan mucha + memoria que debe ser escaneada. -.. vim: set ts=2 sts=2 sw=2 et tw=75 : +.. vim: set ts=3 sts=3 sw=3 et tw=78 spelllang=es :