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
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=3 sts=3 sw=3 et tw=78 :
+.. vim: set ts=3 sts=3 sw=3 et tw=78 spelllang=es :
projects / z.facultad / 75.00 / informe.git / blobdiff