Mostrar algoritmo de mark() más parecido al real

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

diff --git a/source/conclusion.rst b/source/conclusion.rst
index 2de8ffda74b755f7ef856ac10f38bde575677f42..7264b44c1c07c0be316c6f2a8fa343b871ac23f0 100644 (file)
--- a/source/conclusion.rst
+++ b/source/conclusion.rst
@@ -5,7 +5,7 @@
    ESTADO: SIN EMPEZAR
 
 
    ESTADO: SIN EMPEZAR
 
 

-.. _ref_conclusion:
+.. _conclusion:

 
 Conclusión
 ============================================================================
 
 Conclusión
 ============================================================================


@@ -13,12 +13,33 @@ Conclusión
 TODO
 
 
 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
 
 
 Trabajos relacionados
 ----------------------------------------------------------------------------
 
 TODO
 

+* Diamond:
+  http://thecybershadow.net/d/Memory_Management_in_the_D_Programming_Language.pdf

 
 
 Trabajos futuros
 
 
 Trabajos futuros


@@ -26,6 +47,17 @@ Trabajos futuros
 
 TODO
 
 
 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 :