source/conclusion.rst

   1
   2 .. Se presentan las conclusiones del trabajo, comparando los resultados
   3    obtenidos con el punto de partida. Se mencionan puntos pendientes o
   4    nuevas líneas de investigación.
   5    ESTADO: SIN EMPEZAR
   6
   7
   8 .. _conclusion:
   9
  10 Conclusión
  11 ============================================================================
  12
  13 TODO
  14
  15
  16 Puntos pendientes
  17 ----------------------------------------------------------------------------
  18
  19 TODO
  20
  21 * Opciones log_file/verbose
  22 * Lazy sweeping.
  23 * Concurrent sweeping (lanzar fase de sweep en un thread que no pertenezca al
  24   mutator).
  25 * Continuous collection (lanzar un thread que esté haciendo fullcollect() en
  26   un loop). Lo bueno es que el sweep podría correr en ese thread, bajando aún
  27   más el tiempo máximo de pausa (aunque esto se puede hacer más allá de hacer
  28   continuous collection, ver "concurrent sweeping"), lo malo es que tal vez se
  29   estaría recolectando demasiado sin ninguna ganancia substancial.
  30 * Medir mejor cuando lanzar una recolección cuando se usa early collection
  31   (por ejemplo medir la tasa de alocación y el tiempo de recolección y así
  32   hallar el momento ideal para lanzar la recolección).
  33 * Emprolijar todavía más el código (o reescribirlo).
  34
  35
  36 Trabajos relacionados
  37 ----------------------------------------------------------------------------
  38
  39 TODO
  40
  41 * Diamond:
  42   http://thecybershadow.net/d/Memory_Management_in_the_D_Programming_Language.pdf
  43
  44
  45 Trabajos futuros
  46 ----------------------------------------------------------------------------
  47
  48 TODO
  49
  50 * Cambiar el layout de memoria (mostrar lo encontrado en el post). Se podría
  51   usar un tamaño de bloque por cada tipo de dato (y por lo tanto una lista de
  52   libres por cada tipo de dato). Esto podría ahorrar muchos bits (mark,
  53   freebits, scan, etc.), el puntero al pointer mask se guardaría una sola vez,
  54   no hay ningún desperdicio de espacio salvo algún padding, pero podrían haber
  55   esquemas donde ni siquiera (si siempre se alocan tantas páginas como sean
  56   necesarias para evitar el padding para un tamaño de bloque). Un tipo de dato
  57   NO_SCAN no alocaría directamente bits de noscan, mark y scan. Se podría
  58   tratar de forma especial a strings.
  59 * Hacer preciso el static data por el tema de los TypeInfo's que ocupan mucha
  60   memoria que debe ser escaneada.
  61
  62
  63 .. vim: set ts=3 sts=3 sw=3 et tw=78 spelllang=es :