source/dgc.rst

   1
   2 .. Describe más detalladamente los problemas actuales del recolector de
   3    basura de D, sentando las bases para el análisis de los requerimientos
   4    de recolección de basura en dicho lenguaje (se explica por qué las
   5    particularidades descriptas en la sección anterior complican la
   6    recolección de basura y cuales son las que más molestan).
   7    ESTADO: TERMINADO
   8
   9
  10 .. _dgc:
  11
  12 Recolección de basura en D
  13 ============================================================================
  14
  15 D_ propone un nuevo desafío en cuanto al diseño de un recolector de basura,
  16 debido a la gran cantidad características que tiene y paradigmas que soporta.
  17
  18 D_ ya cuenta con un recolector que hace lo necesario para funcionar de forma
  19 aceptable, pero su diseño e implementación son relativamente sencillas
  20 comparadas con el :ref:`estado del arte <gc_art>` de la recolección de basura
  21 en general. Además la implementación actual presenta una serie de problemas
  22 que se evidencia en las quejas que regularmente la comunidad de usuarios de D_
  23 menciona en el grupo de noticias.
  24
  25 En esta sección se analizarán las necesidades particulares de D_ con respecto
  26 a la recolección de basura. También se analiza el diseño e implementación del
  27 recolector actual y finalmente se presenta una recompilación de los
  28 principales problemas que presenta.
  29
  30
  31
  32 .. _dgc_needs:
  33
  34 Características y necesidades particulares de D_
  35 ----------------------------------------------------------------------------
  36
  37 En esta sección se hará un recorrido por las características y necesidades
  38 particulares que tiene D_ como lenguaje con respecto a la recolección de
  39 basura.
  40
  41
  42
  43 .. _dgc_prob_low_level:
  44
  45 Programación de bajo nivel (*system programming*)
  46 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  47
  48 Sin dudas las características de D_ que lo hacen más complejo a la hora de
  49 implementar un recolector de basura son sus capacidades de programación de
  50 bajo nivel (ver :ref:`d_low_level`).
  51
  52 Al proveer acceso a *assembly*, permitir estructuras de tipo *union* y ser
  53 compatible con C/C++, el recolector de basura tiene muchas restricciones. Por
  54 ejemplo debe tratar de forma conservativa los registros y el *stack*, ya que
  55 es la única forma de interactuar de forma segura con C/C++ y *assembly*.
  56
  57 Además debe poder interactuar con manejo de memoria explícito, ya sea
  58 omitiendo por completo el *heap* del recolector o liberando explícitamente
  59 memoria de éste. Esta característica es muy inusual en un recolector,
  60 a excepción de recolectores conservativos diseñados para C/C++ que tienen las
  61 mismas (o más) limitaciones.
  62
  63 El control sobre la alineación de memoria es otra complicación sobre el
  64 recolector de basura, incluso aunque éste sea conservativo. Dado que tratar la
  65 memoria de forma conservativa byte a byte sería impracticable (tanto por la
  66 cantidad de falsos positivos que esto provocaría como por el impacto en el
  67 rendimiento por el exceso de posibles punteros a revisar, además de lo
  68 ineficiente que es operar sobre memoria no alineada), en general el recolector
  69 asume que el usuario nunca va a tener la única referencia a un objeto en una
  70 estructura no alineada al tamaño de palabra.
  71
  72
  73
  74 .. _d_prob_high_level:
  75
  76 Programación de alto nivel
  77 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  78
  79 Las características de programación de alto nivel también impone dificultades
  80 o restricciones al recolector de basura (ver :ref:`d_high_level`). Por ejemplo
  81 el soporte de rebanado (*slicing*) de arreglos hace que el recolector deba
  82 soportar punteros *interiores* [#dgcinterior]_ (esto también es necesario
  83 porque en general en D_ o en cualquier lenguaje de bajo nivel se puede tener
  84 un puntero a cualquier parte de una celda).
  85
  86 .. [#dgcinterior] Los punteros *interiores* son aquellos que en vez de apuntar
  87    al inicio de una celda, apuntan a una dirección arbitraria dentro de ella.
  88    Esto no es posible en muchos lenguajes de programación, como por ejemplo
  89    Java_, lo que simplifica la recolección de basura.
  90
  91 Los arreglos dinámicos y asociativos en particular dependen fuertemente del
  92 recolector de basura, en particular cuando se agregan elementos (o se
  93 concatenan dos arreglos).
  94
  95 Dado que los *strings* son arreglos dinámicos y que el lenguaje provee un buen
  96 soporte de arreglos dinámicos y asociativos y *slicing*, es de esperarse que
  97 el recolector deba comportarse de forma correcta y eficiente ante las
  98 operaciones más típicas de estas estructuras que dependan de él.
  99
 100
 101
 102 .. _dgc_prob_types:
 103
 104 Información de tipos
 105 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 106
 107 Hasta aquí D_ comparte todas las restricciones con respecto a la recolección
 108 de basura con los lenguajes de bajo nivel que no tienen ningún soporte para
 109 recolectar basura. Sin embargo, a diferencia de éstos, D_ tiene una
 110 información de tipos más rica. Al momento de asignar memoria D_ puede proveer
 111 cierta información sobre el objeto a asignar (como si puede contener punteros
 112 o no) que puede ser utilizada por el recolector para realizar una recolección
 113 más precisa (ver :ref:`gc_conserv`).
 114
 115 En general esta información no es suficiente como para implementar un
 116 recolector completamente preciso (no al menos sin agregar un mejor soporte de
 117 reflexión al lenguaje) pero puede ser de ayuda considerable para el
 118 recolector.
 119
 120
 121
 122 .. _dgc_prob_final:
 123
 124 Orientación a objetos y finalización
 125 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 126
 127 D_ soporta el paradigma de orientación a objetos, donde es común permitir que
 128 un objeto, al ser destruido, realice alguna tarea de finalización (a través de
 129 una función miembro llamada *destructor*, o ``~this()`` en D_). Esto significa
 130 que el recolector, al encontrar que no hay más referencias a un objeto, debe
 131 ejecutar el destructor.
 132
 133 La especificación dice:
 134
 135    The garbage collector is not guaranteed to run the destructor for all
 136    unreferenced objects. Furthermore, the order in which the garbage collector
 137    calls destructors for unreference objects is not specified. This means that
 138    when the garbage collector calls a destructor for an object of a class that
 139    has members that are references to garbage collected objects, those
 140    references may no longer be valid. This means that destructors cannot
 141    reference sub objects.
 142
 143 Afortunadamente el orden de finalización no está definido, ya que esto sería
 144 extremadamente difícil de proveer por un recolector (si no imposible). Esto
 145 significa que si bien se ejecutan el destructores de los objetos que dejan de
 146 ser alcanzables desde el *root set*, no se define en que orden se hace, y por
 147 lo tanto un objeto no puede acceder a sus atributos que sean referencias
 148 a otros objetos en un destructor.
 149
 150 Esta restricción en realidad se ve relaja con el soporte de *RAII*. Si se
 151 utiliza la palabra clave ``scope`` al crear una serie de objetos, estos serán
 152 destruidos determinísticamente al finalizar el *scope* actual en el orden
 153 inverso al que fueron creados y, por lo tanto, un usuario podría hacer uso de
 154 los atributos que sean referencias a otros objetos creados con ``scope`` si el
 155 orden en que fueron creados (y por lo tanto en que serán destruidos) se lo
 156 permite.
 157
 158 Sin embargo no hay forma actualmente de saber dentro de un destructor si este
 159 fue llamado determinísticamente o no, por lo tanto es virtualmente imposible
 160 hacer uso de esta distinción, a menos que una clase sea declarada para ser
 161 creada solamente utilizando la palabra reservada ``scope``.
 162
 163 Cabe aclarar que estrictamente hablando, según la especificación de D_, el
 164 recolector no debe garantizar la finalización de objetos bajo ninguna
 165 circunstancia, es decir, el recolector podría no llamar a ningún destructor.
 166 Sin embargo esto es probablemente un problema de redacción vaga y dadas las
 167 garantías que provee la implementación actual la comunidad de D_ cuenta con
 168 ellas porque además son deseables (y sencillas de implementar).
 169
 170
 171
 172 .. _dgc_actual:
 173
 174 Recolector de basura actual de D
 175 ----------------------------------------------------------------------------
 176
 177 Como paso básico fundamental para poder mejorar el recolector de basura de D_,
 178 primero hay que entender la implementación actual, de forma de conocer sus
 179 puntos fuertes, problemas y limitaciones, de manera tal de poder analizar
 180 formas de mejorarlo.
 181
 182 Como se mencionó en la sección :ref:`d_lang`, en D_ hay dos bibliotecas base
 183 para soportar el lenguaje (*runtimes*): Phobos_ y Tango_. La primera es la
 184 biblioteca estándar de D_, la segunda un proyecto más abierto y dinámico que
 185 surgió como alternativa a Phobos_ debido a que Phobos_ es muy descuidada y que
 186 era muy difícil impulsar cambios en ella. Ahora Phobos_ tiene el agravante de
 187 estar *congelada* en su versión 1 (solo se realizan correcciones de errores).
 188
 189 Dado que Tango_ está mejor organizada, su desarrollo es más abierto (aceptan
 190 cambios y mejoras) y que hay una mayor disponibilidad de programas
 191 y bibliotecas escritos para Tango_, en este trabajo se decide tomar esta
 192 biblioteca *runtime* como base para el análisis y mejoras propuestas, a pesar
 193 de ser Phobos_ la estándar. De todas formas el recolector de basura de Tango_
 194 es prácticamente el mismo que el de Phobos_, por lo tanto éste análisis en
 195 particular es válido para cualquiera de las dos.
 196
 197 El recolector actual es un recolector :ref:`indirecto <gc_direct>`, :ref:`no
 198 incremental <gc_inc>` que realiza un :ref:`marcado y barrido <gc_mark_sweep>`
 199 relativamente básico.  A diferencia del algoritmo clásico presentado éste
 200 realiza un marcado no recursivo. La fase de marcado es :ref:`stop-the-world
 201 <gc_concurrent` mientras que la fase de barrido corre en paralelo con el
 202 *mutator*, excepto el hilo que disparó la recolección que es quien efectúa el
 203 barrido (además los hilos que intenten asignar nueva memoria o interactuar con
 204 el recolector de cualquier otra forma se bloquean hasta que la fase de barrido
 205 concluya). El marcado es casi totalmente :ref:`conservativo <gc_conserv>`; si
 206 bien posee alguna información de tipos (distingue entre celdas que pueden
 207 tener punteros y celdas que definitivamente no los tienen, pero no dispone de
 208 información sobre qué campos de las celdas son punteros y cuales no). Además
 209 no tiene soporte alguno de :ref:`recolección particionada <gc_part>`.
 210
 211 Si bien el recolector es bastante básico, posee una :ref:`organización de
 212 memoria <dgc_org>` relativamente moderna (utiliza una :ref:`lista de libres
 213 <gc_free_list>` con un *two level allocator*) y algunas optimizaciones
 214 particulares para amortiguar casos patológicos.
 215
 216
 217 .. _dgc_org:
 218
 219 Organización del *heap*
 220 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 221
 222 La memoria del *heap* está organizada en *pools*. Un *pool* es una región de
 223 *páginas* contiguas. Una página es, en general, la unidad mínima de memoria que
 224 maneja un sistema operativo con soporte de memoria virtual. Cada página dentro
 225 de un *pool* sirve a su vez como contenedora de bloques (llamados *bin* en la
 226 :ref:`implementación <dgc_impl>`) de tamaño fijo. Todos los bloques
 227 pertenecientes a la misma página tienen el mismo tamaño de bloque (ver figura
 228 :vref:`fig:dgc-org`). Los tamaños de bloque posibles son potencias de 2 desde
 229 16 bytes hasta 4096 (el tamaño típico de una página), es decir: 16, 32, 64,
 230 128, 256, 512, 1024, 2048 y 4096 [#dgcpageplus]_. Todos los objetos, arreglos
 231 o celdas en general se ubican en estos bloques (en uno del tamaño más pequeño
 232 que haya que sea suficientemente grande como para almacenar dicho objeto).  En
 233 caso de que un objeto sea mayor a una página, se utilizan la menor cantidad de
 234 páginas contiguas de un pool que tengan espacio suficiente para almacenar
 235 dicho objeto.
 236
 237 .. [#dgcpageplus] Además existe otro tamaño de bloque especial que se utiliza
 238    para indicar la continuación de un objeto grande (que ocupan más de una
 239    página).
 240
 241 .. fig:: fig:dgc-org
 242
 243    Organización del *heap* del recolector de basura actual de D.
 244
 245    Organización del *heap*. En este ejemplo todos los *pools* tienen 2 páginas
 246    excepto el *pool* 2 que tiene una sola.  El tamaño de bloque que almacena
 247    cada página varía entre 64 bytes (página 0 del *pool* 2) hasta 4096 (ambas
 248    páginas del *pool* N) que es una página completa.
 249
 250    .. aafig::
 251       :scale: 120
 252
 253       +----------------------------------------------------------------------+
 254       |                                 Heap                                 |
 255       +======================================================================+
 256       |   "Pool 0"     "Pool 1"     "Pool 2"     "Pool 3"   ...   "Pool N"   |
 257       | +----------+ +----------+ +----------+ +----------+     +----------+ |
 258       | | Página 0 | | Página 0 | | Página 0 | | Página 0 | ... | Página 0 | |
 259       | |  (8x512) | | (4x1024) | |  (64x64) | | (2x2048) | ... | (1x4096) | |
 260       | |+--------+| |+--------+| |+--------+| |+--------+|     |+--------+| |
 261       | || Bloque || ||        || ||qqqqqqqq|| ||        ||     ||        || |
 262       | |+--------+| || Bloque || ||qqqqqqqq|| ||        ||     ||        || |
 263       | || Bloque || ||        || ||qqqqqqqq|| ||        ||     ||        || |
 264       | |+--------+| |+--------+| ||qqqqqqqq|| || Bloque ||     ||        || |
 265       | || Bloque || ||        || ||qqqqqqqq|| ||        ||     ||        || |
 266       | |+--------+| || Bloque || ||qqqqqqqq|| ||        ||     ||        || |
 267       | || Bloque || ||        || ||qqqqqqqq|| ||        ||     ||        || |
 268       | |+--------+| |+--------+| ||qqqqqqqq|| |+--------+|     || Bloque || |
 269       | || Bloque || ||        || ||qqqqqqqq|| ||        ||     ||        || |
 270       | |+--------+| || Bloque || ||qqqqqqqq|| ||        ||     ||        || |
 271       | || Bloque || ||        || ||qqqqqqqq|| ||        ||     ||        || |
 272       | |+--------+| |+--------+| ||qqqqqqqq|| || Bloque ||     ||        || |
 273       | || Bloque || ||        || ||qqqqqqqq|| ||        ||     ||        || |
 274       | |+--------+| || Bloque || ||qqqqqqqq|| ||        ||     ||        || |
 275       | || Bloque || ||        || ||qqqqqqqq|| ||        ||     ||        || |
 276       | |+--------+| |+--------+| |+--------+| |+--------+|     |+--------+| |
 277       | | Página 1 | | Página 1 | +----------+ | Página 1 | ... | Página 1 | |
 278       | | (16x256) | |  (8x512) |              | (32x128) | ... | (1x4096) | |
 279       | |+--------+| |+--------+|              |+--------+|     |+--------+| |
 280       | |+--------+| || Bloque ||              ||nnnnnnnn||     ||        || |
 281       | |+--------+| |+--------+|              ||nnnnnnnn||     ||        || |
 282       | |+--------+| || Bloque ||              ||nnnnnnnn||     ||        || |
 283       | |+--------+| |+--------+|              ||nnnnnnnn||     ||        || |
 284       | |+--------+| || Bloque ||              ||nnnnnnnn||     ||        || |
 285       | |+--------+| |+--------+|              ||nnnnnnnn||     ||        || |
 286       | |+--------+| || Bloque ||              ||nnnnnnnn||     ||        || |
 287       | |+--------+| |+--------+|              ||nnnnnnnn||     || Bloque || |
 288       | |+--------+| || Bloque ||              ||nnnnnnnn||     ||        || |
 289       | |+--------+| |+--------+|              ||nnnnnnnn||     ||        || |
 290       | |+--------+| || Bloque ||              ||nnnnnnnn||     ||        || |
 291       | |+--------+| |+--------+|              ||nnnnnnnn||     ||        || |
 292       | |+--------+| || Bloque ||              ||nnnnnnnn||     ||        || |
 293       | |+--------+| |+--------+|              ||nnnnnnnn||     ||        || |
 294       | |+--------+| || Bloque ||              ||nnnnnnnn||     ||        || |
 295       | |+--------+| |+--------+|              |+--------+| ... |+--------+| |
 296       | +----------+ +----------+              +----------+     +----------+ |
 297       +----------------------------------------------------------------------+
 298
 299 Cada página de un *pool* puede estar asignada a contener bloques de un tamaño
 300 específico o puede estar libre. A su vez, cada bloque puede estar ocupado por
 301 una celda o estar libre. Los bloques libres de un tamaño específico (a
 302 excepción de aquellos bloques que ocupen una página entera) además forman
 303 parte de una :ref:`lista de libres <gc_free_list>` (ver figura
 304 :vref:`fig:dgc-free-list`). Esto permite asignar objetos relativamente
 305 pequeños de forma bastante eficiente.
 306
 307 .. fig:: fig:dgc-free-list
 308
 309    Ejemplo de listas de libres.
 310
 311    .. digraph:: dgc_free_list
 312
 313       margin  = 0;
 314       rankdir = LR;
 315       ratio   = fill;
 316       size    = "4.6,3.6";
 317       node [ shape = record, width = 0, height = 0 ];
 318
 319       subgraph cluster_heap {
 320          style = solid;
 321          color = black;
 322
 323          free [ label = "Libres|<p16> 16|<p32> 32|<p64> 64|<p128> 128|<p256> 256|<p512> 512|<p1024> 1024|<p2048> 2048" ];
 324
 325          free:p16 -> b1 -> b2 -> b3;
 326          free:p32 -> b4 -> b5 -> b6 -> b7 -> b8;
 327          // free:p64 is empty
 328          free:p128 -> b9;
 329          free:p256 -> b10 -> b11;
 330          free:p512 -> b12;
 331          free:p1024 -> b13 -> b14;
 332          free:p2048 -> b15 -> b16 -> b17;
 333       }
 334
 335
 336 Atributos de *pool*
 337 ^^^^^^^^^^^^^^^^^^^
 338 Cada *pool* tiene la siguiente información asociada:
 339
 340 *number_of_pages*
 341    cantidad de páginas que tiene. Esta cantidad es fija en toda la vida de un
 342    *pool*.
 343
 344 *pages*
 345    bloque de memoria contiguo de tamaño ``PAGE_SIZE * number_of_pages``
 346    (siendo ``PAGE_SIZE`` el tamaño de página, que normalmente son 4096 bytes).
 347
 348
 349 Atributos de página
 350 ^^^^^^^^^^^^^^^^^^^
 351 Cada página dentro de un *pool* tiene un único atributo asociado: *block_size*.
 352 Se trata del tamaño de los bloques que almacena esta página.
 353
 354 Una página siempre almacena bloques del mismo tamaño, que pueden ser 16, 32,
 355 64, 128, 256, 512, 1024, 2048 o 4096 (llamado con el nombre especial
 356 ``PAGE``). Además hay dos tamaños de bloque simbólicos que tienen un
 357 significado especial:
 358
 359 ``FREE``
 360    indica que la página está completamente libre y que la página está
 361    disponible para albergar cualquier tamaño de bloque que sea necesario (pero
 362    una vez que se le asignó un nuevo tamaño de bloque ya no puede ser cambiado
 363    hasta que la página vuelva a liberarse por completo).
 364
 365 ``CONTINUATION``
 366    indica que esta página es la continuación de un objeto grande (es decir,
 367    que ocupa una o más páginas). Luego se presentan más detalles sobre objetos
 368    grandes.
 369
 370 Las páginas con esto tamaños de bloque especiales (conceptualmente) no
 371 contienen bloques.
 372
 373
 374 Atributos de bloque
 375 ^^^^^^^^^^^^^^^^^^^
 376 Cada bloque tiene asociados varios atributos:
 377
 378 *mark*
 379    utilizado en la fase de :ref:`marcado <dgc_algo_mark>`, indica que un nodo
 380    ya fue visitado (serían las celdas *negras* en la :ref:`abstracción
 381    tricolor <gc_intro_tricolor>`).
 382
 383 *scan*
 384    utilizado también en la fase de :ref:`marcado <dgc_algo_mark>`, indica que
 385    una celda visitada todavía tiene *hijas* sin marcar (serían las celdas
 386    *grises* en la :ref:`abstracción tricolor <gc_intro_tricolor>`).
 387
 388 *free*
 389    indica que el bloque está libre (no está siendo utilizado por ningún objeto
 390    *vivo*). Esto es necesario solo por la forma en la que realiza el
 391    :ref:`marcado <dgc_algo_mark>` y :ref:`barrido <dgc_algo_sweep>` en el
 392    :ref:`algoritmo actual <dgc_algo>` (las celdas con el atributo este
 393    atributo son tomadas como *basura* aunque estén marcadas con *mark*).
 394
 395 *final*
 396    indica que el bloque contiene un objeto que tiene un destructor (que debe
 397    ser llamado cuando la celda pasa de *viva* a *basura*).
 398
 399 *noscan*
 400    indica que el bloque contiene un objeto que no tiene punteros y por lo
 401    tanto no debe ser marcado de forma conservativa (no tiene *hijas*).
 402
 403
 404 Objetos grandes
 405 ^^^^^^^^^^^^^^^
 406 El recolector de basura actual de D_ trata de forma diferente a los objetos
 407 grandes. Todo objeto grande empieza en un bloque con tamaño ``PAGE``
 408 y (opcionalmente) continúa en los bloques contiguos subsiguientes que tengan
 409 el tamaño de bloque ``CONTINUATION`` (si el objeto ocupa más que una página).
 410 El fin de un objeto grande queda marcado por el fin del *pool* o una página
 411 con tamaño de bloque distinto a ``CONTINUATION`` (lo que suceda primero).
 412
 413 Cuando un objeto grande se convierte en *basura*, todas sus páginas se liberan
 414 por completo, siendo marcadas con tamaño ``FREE`` para que puedan ser
 415 almacenado en ellas otros objetos grandes o incluso nuevos bloques de un
 416 tamaño determinado.
 417
 418
 419
 420 .. _dgc_algo:
 421
 422 Algoritmos del recolector
 423 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 424
 425 A continuación se explica como provee el recolector actual de D_ los servicios
 426 básicos que debe proveer cualquier recolector, como se presentó en la sección
 427 :ref:`gc_intro_services`.
 428
 429 Cabe aclarar que se presenta una versión simplificada del algoritmo, o más
 430 precisamente, de la implementación del algoritmo, ya que no se exponen en esta
 431 sección muchas optimizaciones que harían muy compleja la tarea de explicar
 432 como funciona conceptualmente. En la siguiente sección, :ref:`dgc_impl`, se
 433 darán más detalles sobre las optimizaciones importantes y diferencias con el
 434 algoritmo aquí presentado, junto con detalles sobre como se implementa la
 435 organización del *heap* que se explicó en la sección anterior.
 436
 437
 438 .. _dgc_algo_collect:
 439
 440 Recolección
 441 ^^^^^^^^^^^
 442 A grandes rasgos el algoritmo de recolección puede resumirse de las dos fases
 443 básicas de cualquier algoritmo de :ref:`marcado y barrido <gc_mark_sweep>`::
 444
 445    function collect() is
 446       mark_phase()
 447       sweep_phase()
 448
 449
 450 .. _dgc_algo_mark:
 451
 452 Fase de marcado
 453 ^^^^^^^^^^^^^^^
 454 Esta fase consiste de varios pasos, que pueden resumirse en el siguiente
 455 algoritmo::
 456
 457    function mark_phase() is
 458       global more_to_scan = false
 459       stop_the_world()
 460       clear_mark_scan_bits()
 461       mark_free_lists()
 462       mark_static_data()
 463       push_registers_into_stack()
 464       thread_self.stack.end = get_stack_top()
 465       mark_stacks()
 466       pop_registers_from_stack()
 467       mark_user_roots()
 468       mark_heap()
 469       start_the_world()
 470
 471 La variable **global** ``more_to_scan`` indica al algoritmo iterativo cuando
 472 debe finalizar: la función ``mark_range()`` (que veremos más adelante) lo pone
 473 en ``true`` cuando una nueva celda debe ser visitada, por lo tanto la
 474 iteración se interrumpe cuando no hay más celdas por visitar.
 475
 476 Las funciones ``stop_the_world()`` y ``start_the_world()`` pausan y reanudan
 477 todos los hilos respectivamente (salvo el actual). Al pausar los hilos además
 478 se guardan los registros del procesador en el *stack* y se guarda la posición
 479 actual del *stack* para que la fase de marcado pueda recorrerlos::
 480
 481    function stop_the_world() is
 482       foreach thread in threads
 483          if thread is thread_self
 484             continue
 485          thread.pause()
 486          push_registers_into_stack()
 487          thread.stack.end = get_stack_top()
 488
 489    function start_the_world() is
 490       foreach thread in threads
 491          if thread is thread_self
 492             continue
 493          pop_registers_from_stack()
 494          thread.resume()
 495
 496 La función ``clear_mark_scan_bits()`` se encarga de restablecer todos los
 497 atributos *mark* y *scan* de cada bloque del *heap*::
 498
 499    function clear_mark_scan_bits() is
 500       foreach pool in heap
 501          foreach page in pool
 502             foreach block in page
 503                block.mark = false
 504                block.scan = false
 505
 506 La función ``mark_free_lists()`` por su parte se encarga de activar el bit
 507 *mark* de todos los bloques de las listas de libres de manera de que la fase
 508 de marcado (que es iterativa y realiza varias pasadas sobre **todo** el
 509 *heap*, incluyendo las celdas libres) no visite las celdas libres perdiendo
 510 tiempo sin sentido y potencialmente manteniendo *vivas* celdas que en
 511 realidad son *basura* (falsos positivos)::
 512
 513    function mark_free_lists() is
 514       foreach free_list in heap
 515          foreach block in free_list
 516             block.mark = true
 517             block.free = true
 518
 519 Notar que los bloques libres quedan entonces marcados aunque sean *basura* por
 520 definición. Para evitar que en la etapa de barrido se tomen estos bloques como
 521 celdas vivas, a todos los bloques en la lista de libres también se los marca
 522 con el bit *free*, así el barrido puede tomar como *basura* estos bloques
 523 aunque estén marcados.
 524
 525 El *root set* está compuesto por el área de memoria estática (variables
 526 globales), los *stacks* de todos los hilos y los registros del procesador.
 527 Primero se marca el área de memoria estática de manera :ref:`conservativa
 528 <gc_conserv>` (es decir, tomando cada *word* como si fuera un puntero)::
 529
 530    function mark_static_data() is
 531       mark_range(static_data.begin, static_data.end)
 532
 533 Para poder tomar los registros como parte del *root set* primero se apilan
 534 en el *stack* a través de la función::
 535
 536    function push_registers_into_stack() is
 537       foreach register in registers
 538          push(register)
 539
 540 Y luego se descartan (no es necesario ni correcto restablecer los valores ya
 541 que podrían tener nuevos valores) al sacarlos de la pila::
 542
 543    function pop_registers_from_stack() is
 544       foreach register in reverse(registers)
 545          pop()
 546
 547 Una vez hecho esto, basta marcar (de forma conservativa) los *stacks* de todos
 548 los threads para terminar de marcar el *root set*::
 549
 550    function mark_stacks() is
 551       foreach thread in threads
 552          mark_range(thread.stack.begin, thread.stack.end)
 553
 554 Dado que D_ soporta manejo de memoria manual al mismo tiempo que memoria
 555 automática, es posible que existan celdas de memoria que no estén en el *root
 556 set* convencional ni en el *heap* del recolector. Para evitar que se libere
 557 alguna celda a la cual todavía existen referencias desde memoria administrada
 558 por el usuario, éste debe informarle al recolector sobre la existencia de
 559 estas nuevas raíces. Es por esto que para concluir el marcado del *root set*
 560 completo se procede a marcar las raíces definidas por el usuario::
 561
 562    function mark_user_roots() is
 563       foreach root_range in user_roots
 564          mark_range(root_range.begin, root_range.end)
 565
 566 El algoritmo de marcado no es recursivo sino iterativo por lo tanto al marcar
 567 una celda (o bloque) no se siguen sus *hijas*, solo se activa el bit de *scan*
 568 (a menos que la celda no contenga punteros, es decir, tenga el bit *noscan*)::
 569
 570    function mark_range(begin, end) is
 571       pointer = begin
 572       while pointer < end
 573          [pool, page, block] = find_block(pointer)
 574          if block is not null and block.mark is false
 575             block.mark = true
 576             if block.noscan is false
 577                block.scan = true
 578                global more_to_scan = true
 579          pointer++
 580
 581 Por lo tanto en este punto, tenemos todas las celdas inmediatamente
 582 alcanzables desde el *root set* marcadas y con el bit *scan* activado si la
 583 celda puede contener punteros. Por lo tanto solo resta marcar (nuevamente de
 584 forma conservativa) iterativamente todo el *heap* hasta que no hayan más
 585 celdas para visitar (con el bit *scan* activo)::
 586
 587    function mark_heap() is
 588       while global more_to_scan
 589          global more_to_scan = false
 590          foreach pool in heap
 591             foreach page in pool
 592                if page.block_size <= PAGE // saltea FREE y CONTINUATION
 593                   foreach block in page
 594                      if block.scan is true
 595                         block.scan = false
 596                         if page.block_size is PAGE // objeto grande
 597                            begin = cast(byte*) page
 598                            end = find_big_object_end(pool, page)
 599                            mark_range(begin, end)
 600                         else // objeto pequeño
 601                            mark_range(block.begin, block.end)
 602
 603 Aquí puede verse, con un poco de esfuerzo, la utilización de la
 604 :ref:`abstracción tricolor <gc_intro_tricolor>`: todas las celdas alcanzables
 605 desde el *root set* son pintadas de *gris* (tienen los bits *mark* y *scan*
 606 activados), excepto aquellas celdas atómicas (es decir, que se sabe que no
 607 tienen punteros) que son marcadas directamente de *negro*. Luego se van
 608 obteniendo celdas del conjunto de las *grises*, se las pinta de *negro* (es
 609 decir, se desactiva el bit *scan*) y se pintan todas sus *hijas* de *gris* (o
 610 *negro* directamente si no tienen punteros). Este procedimiento se repite
 611 mientras el conjunto de celdas *grises* no sea vacío (es decir, que
 612 ``more_to_scan`` sea ``true``).
 613
 614 A continuación se presenta la implementación de las funciones suplementarias
 615 utilizadas en la fase de marcado::
 616
 617    function find_big_object_end(pool, page) is
 618       pool_end = cast(byte*) pool.pages + (PAGE_SIZE * pool.number_of_pages)
 619       do
 620          page = cast(byte*) page + PAGE_SIZE
 621       while page.block_size is CONTINUATION and page < pool_end
 622       return page
 623
 624    function find_block(pointer) is
 625       foreach pool in heap
 626          foreach page in pool
 627             if page.block_size is PAGE
 628                big_object_start = cast(byte*) page
 629                big_object_end = find_big_object_end(pool, page)
 630                if big_object_start <= pointer < big_object_end
 631                   return [pool, page, big_object_start]
 632             else if page.bloc_size < PAGE
 633                foreach block in page
 634                   block_start = cast(byte*) block
 635                   block_end = block_start + page.block_size
 636                   if block_start <= pointer < block_end
 637                      return [pool, page, block_start]
 638       return [null, null, null]
 639
 640 Cabe destacar que la función ``find_block()`` devuelve el *pool*, la página
 641 y el comienzo del bloque al que apunta el puntero, es decir, soporta punteros
 642 *interiores*.
 643
 644
 645 .. _dgc_algo_sweep:
 646
 647 Fase de barrido
 648 ^^^^^^^^^^^^^^^
 649 Esta fase es considerablemente más sencilla que el marcado; el algoritmo puede
 650 dividirse en dos pasos básicos::
 651
 652    function sweep_phase() is
 653       sweep()
 654       rebuild_free_lists()
 655
 656 El barrido se realiza con una pasada por sobre todo el *heap* de la siguiente
 657 manera::
 658
 659    function sweep() is
 660       foreach pool in heap
 661          foreach page in pool
 662             if page.block_size <= PAGE // saltea FREE y CONTINUATION
 663                foreach block in page
 664                   if block.mark is false
 665                      if block.final is true
 666                         finalize(block)
 667                      block.free = true
 668                      block.final = false
 669                      block.noscan = false
 670                      if page.block_size is PAGE // objeto grande
 671                         free_big_object(pool, page)
 672
 673 Como se observa, se recorre todo el *heap* en busca de bloques y páginas
 674 libres. Los bloques libres son marcados con el atributo ``free`` y las páginas
 675 libres son marcadas con el tamaño de bloque simbólico ``FREE``. Para los
 676 objetos grandes se marcan todas las páginas que utilizaban como ``FREE``::
 677
 678    function free_big_object(pool, page) is
 679       pool_end = cast(byte*) pool.pages + (PAGE_SIZE * pool.number_of_pages)
 680       do
 681          page.block_size = FREE
 682          page = cast(byte*) page + PAGE_SIZE
 683       while page < pool_end and page.block_size is CONTINUATION
 684
 685 Además, los bloques que tienen en atributo ``final`` son finalizados llamando
 686 a la función ``finalize()``. Esta función es un servicio que provee la
 687 biblioteca *runtime* y en última instancia llama al destructor del objeto
 688 almacenado en el bloque a liberar.
 689
 690 Una vez marcados todos los bloques y páginas como libre, se procede
 691 a reconstruir las listas de libres. En el proceso buscan las páginas que
 692 tengan todos los bloques libres para marcar la página completa como libre (de
 693 manera que pueda utilizarse para albergar otro tamaño de bloque u objetos
 694 grandes de ser necesario)::
 695
 696    function rebuild_free_lists() is
 697       foreach free_list in heap
 698          free_list.clear()
 699       foreach pool in heap
 700          foreach page in pool
 701             if page.block_size < PAGE // objetos pequeños
 702                if is_page_free(page)
 703                   page.block_size = FREE
 704                else
 705                   foreach block in page
 706                      if block.free is true
 707                         free_lists[page.block_size].link(block)
 708
 709 Esta reorganización de listas libres además mejoran la localidad de
 710 referencia y previenen la fragmentación. La localidad de referencia se ve
 711 mejorada debido a que asignaciones de memoria próximas en el tiempo serán
 712 también próximas en espacio porque pertenecerán a la misma página (al menos si
 713 las asignaciones son todas del mismo tamaño). La fragmentación se minimiza por
 714 el mismo efecto, primero se asignarán todos los bloques de la misma página.
 715
 716 A continuación se presenta la implementación de una de las funciones
 717 suplementarias de la fase de barrido::
 718
 719    function is_page_free(page) is
 720       foreach block in page
 721          if block.free is false
 722             return false
 723       return true
 724
 725 Las demás funciones suplementarias pertenecen a la manipulación de listas
 726 libres que no son más que operaciones sobre una lista simplemente enlazada. En
 727 la sección :ref:`dgc_impl` se verá con más detalles como las implementa el
 728 recolector actual.
 729
 730
 731 .. _dgc_algo_alloc:
 732
 733 Asignación de memoria
 734 ^^^^^^^^^^^^^^^^^^^^^
 735 La asignación de memoria del recolector es relativamente compleja, excepto
 736 cuando se asigna un objeto pequeño y ya existe algún bloque con el tamaño
 737 preciso en la lista de libres. Para el resto de los casos la cantidad de
 738 trabajo que debe hacer el recolector para asignar la memoria es considerable.
 739
 740 El algoritmo de asignación de memoria se puede resumir así::
 741
 742    function new(size, attrs) is
 743       block_size = find_block_size(size)
 744       if block_size < PAGE
 745          block = new_small(block_size)
 746       else
 747          block = new_big(size)
 748       if block is null
 749          throw out_of_memory
 750       if final in attrs
 751          block.final = true
 752       if noscan in attrs
 753          block.noscan = true
 754       return cast(void*) block
 755
 756 La función ``find_block_size()`` sencillamente busca el tamaño de bloque se
 757 mejor se ajuste al tamaño solicitado (es decir, el bloque más pequeño lo
 758 suficientemente grande como para poder almacenar el tamaño solicitado). Una
 759 vez más el algoritmo distingue objetos grandes de pequeños. Los pequeños se
 760 asignan de las siguiente manera::
 761
 762    function new_small(block_size) is
 763       block = find_block_with_size(block_size)
 764       if block is null
 765          collect()
 766          block = find_block_with_size(block_size)
 767          if block is null
 768             new_pool()
 769             block = find_block_with_size(block_size)
 770       return block
 771
 772 Se intenta reiteradas veces conseguir un bloque del tamaño correcto libre,
 773 realizando diferentes acciones si no se tiene éxito. Primero se intenta hacer
 774 una :ref:`recolección <dgc_algo_collect>` y si no se puede encontrar
 775 suficiente espacio luego de ella se intenta crear un nuevo *pool* de memoria
 776 pidiendo memoria al *low level allocator* (el sistema operativo generalmente).
 777
 778 Para intentar buscar un bloque de memoria libre se realiza lo siguiente::
 779
 780    function find_block_with_size(block_size) is
 781       block = free_lists[block_size].pop_first()
 782       if block is null
 783          assign_page(block_size)
 784          block = free_lists[block_size].pop_first()
 785       return block
 786
 787 Si no se puede obtener un bloque de la lista de libres correspondiente, se
 788 busca asignar una página libre al tamaño de bloque deseado de forma de
 789 *alimentar* la lista de libres con dicho tamaño::
 790
 791    function assign_page(block_size) is
 792       foreach pool in heap
 793          foreach page in pool
 794             if page.block_size is FREE
 795                page.block_size = block_size
 796                foreach block in page
 797                   free_lists[page.block_size].link(block)
 798
 799 Cuando todo ello falla, el último recurso consiste en pedir memoria al sistema
 800 operativo, creando un nuevo *pool*::
 801
 802    function new_pool(number_of_pages = 1) is
 803       pool = alloc(pool.sizeof)
 804       if pool is null
 805          return null
 806       pool.number_of_pages = number_of_pages
 807       pool.pages = alloc(number_of_pages * PAGE_SIZE)
 808       if pool.pages is null
 809          free(pool)
 810          return null
 811       heap.add(pool)
 812       foreach page in pool
 813          page.block_size = FREE
 814       return pool
 815
 816 Se recuerda que la función ``alloc()`` es un :ref:`servicio
 817 <gc_intro_services>` provisto por el *low level allocator* y en la
 818 implementación actual de D_ en general es el sistema operativo (aunque
 819 opcionalmente puede utilizarse la biblioteca estándar de C, que a su vez
 820 utiliza el sistema operativo).
 821
 822 Cualquier error en estas funciones es propagado y en última instancia, cuando
 823 todo falla, la función ``new()`` termina lanzando una excepción indicando que
 824 se agotó la memoria.
 825
 826 Si el tamaño de bloque necesario para cumplir con la asignación de memoria es
 827 de una página, entonces se utiliza otro algoritmo para alocar un objeto
 828 grande::
 829
 830    function new_big(size) is
 831       number_of_pages = ceil(size / PAGE_SIZE)
 832       pages = find_pages(number_of_pages)
 833       if pages is null
 834          collect()
 835          pages = find_pages(number_of_pages)
 836          if pages is null
 837             minimize()
 838             pool = new_pool(number_of_pages)
 839             if pool is null
 840                return null
 841             pages = assign_pages(pool, number_of_pages)
 842       pages[0].block_size = PAGE
 843       foreach page in pages[1..end]
 844          page.block_size = CONTINUATION
 845       return pages[0]
 846
 847 De forma similar a la asignación de objetos pequeños, se intenta encontrar una
 848 serie de páginas contiguas, dentro de un mismo *pool*, suficientes para
 849 almacenar el tamaño requerido y si esto falla, se realizan diferentes pasos
 850 y se vuelve a intentar. Puede observarse que, a diferencia de la asignación de
 851 objetos pequeños, si luego de la recolección no se pudo encontrar lugar
 852 suficiente, se trata de minimizar el uso de memoria física utilizando la
 853 siguiente función, que devuelve al *low level allocator* los *pools*
 854 completamente libres::
 855
 856    function minimize() is
 857       foreach pool in heap
 858          all_free = true
 859          foreach page in pool
 860             if page.block_size is not FREE
 861                all_free = false
 862                break
 863          if all_free is true
 864             free(pool.pages)
 865             free(pool)
 866             heap.remove(pool)
 867
 868 Volviendo a la función ``new_big()``, para hallar una serie de páginas
 869 contiguas se utiliza el siguiente algoritmo::
 870
 871    function find_pages(number_of_pages) is
 872       foreach pool in heap
 873          pages = assign_pages(pool, number_of_pages)
 874          if pages
 875             return pages
 876       return null
 877
 878 Como se dijo, las páginas deben estar contenidas en un mismo *pool* (para
 879 tener la garantía de que sean contiguas), por lo tanto se busca *pool* por
 880 *pool* dicha cantidad de páginas libres consecutivas a través del siguiente
 881 algoritmo::
 882
 883    function assign_pages(pool, number_of_pages) is
 884       pages_found = 0
 885       first_page = null
 886       foreach page in pool
 887          if page.block_size is FREE
 888             if pages_found is 0
 889                pages_found = 1
 890                first_page = page
 891             else
 892                pages_found = pages_found + 1
 893             if pages_found is number_of_pages
 894                return [first_page .. page]
 895          else
 896             pages_found = 0
 897             first_page = null
 898       return null
 899
 900 Una vez más, cuando todo ello falla (incluso luego de una recolección), se
 901 intenta alocar un nuevo *pool*, esta vez con una cantidad de páginas
 902 suficientes como para almacenar el objeto grande y si esto falla el error se
 903 propaga hasta la función ``new()`` que lanza una excepción.
 904
 905
 906 .. _dgc_algo_free:
 907
 908 Liberación de memoria
 909 ^^^^^^^^^^^^^^^^^^^^^
 910 La liberación de la memoria asignada puede hacerse explícitamente. Esto
 911 saltea el mecanismo de recolección, y es utilizado para dar soporte a manejo
 912 explícito de memoria asignada en el *heap* del recolector. En general el
 913 usuario no debe utilizar liberación explícita, pero puede ser útil en casos
 914 muy particulares::
 915
 916    function delete(pointer) is
 917       [pool, page, block_start] = find_block(pointer)
 918       if block is not null
 919          block.free = true
 920          block.final = false
 921          block.noscan = false
 922          if page.block_size is PAGE // objeto grande
 923             free_big_object(pool, page)
 924          else // objeto pequeño
 925             free_lists[page.block_size].link(block)
 926
 927 Como se puede observar, si el objeto es pequeño se enlaza a la lista de libres
 928 correspondiente y si es grande se liberan todas las páginas asociadas a éste,
 929 de forma similar a la :ref:`fase de barrido <dgc_algo_sweep>`. A diferencia de
 930 ésta, no se finaliza el objeto (es decir, no se llama a su destructor).
 931
 932
 933 .. _dgc_algo_final:
 934
 935 Finalización
 936 ^^^^^^^^^^^^
 937 Al finalizar el programa, el recolector es finalizado también y lo que realiza
 938 actualmente, además de liberar la memoria propia del recolector, es realizar
 939 una recolección. Es decir, si hay objetos que son todavía alcanzables desde el
 940 *root set*, esos objetos no son finalizados (y por lo tanto sus destructores
 941 no son ejecutados).
 942
 943 Como se ha visto, esto es perfectamente válido ya que D_ no garantiza que los
 944 objetos sean finalizados.
 945
 946
 947
 948 .. _dgc_impl:
 949
 950 Detalles de implementación
 951 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 952
 953 Hay varias diferencias a nivel de implementación entre lo que se presentó en
 954 las secciones anteriores y como está implementado realmente el recolector
 955 actual. Con los conceptos e ideas principales del ya explicadas, se procede
 956 a ahondar con más detalle en como está construido el recolector y algunas de
 957 sus optimizaciones principales.
 958
 959 Vale aclarar que el recolector de basura actual está implementado en D_.
 960
 961
 962 Estructuras de datos del recolector
 963 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 964 El recolector está principalmente contenido en la estructura llamada ``Gcx``.
 965 Dicha estructura tiene los siguientes atributos (divididos en categorías para
 966 facilitar la comprensión):
 967
 968 Raíces definidas por el usuario
 969    *roots* (*nroots*, *rootdim*)
 970       arreglo variable de punteros simples que son tomados como raíces
 971       provistas por el usuario.
 972
 973    *ranges* (*nranges*, *rangedim*)
 974       arreglo variable de rangos de memoria que deben ser revisados (de forma
 975       conservativa) como raíces provistas por el usuario. Un rango es una
 976       estructura con dos punteros: ``pbot`` y ``ptop``. Toda la memoria entre
 977       estos dos punteros se toma, palabra por palabra, como una raíz del
 978       recolector.
 979
 980 Estado interno del recolector
 981    *anychanges*
 982       variable que indica si en la fase de marcado se encontraron nuevas
 983       celdas con punteros que deban ser visitados. Otra forma de verlo es como
 984       un indicador de si el conjunto de celdas *grises* está vacío luego de
 985       una iteración de marcado (utilizando la :ref:`abstracción tricolor
 986       <gc_intro_tricolor>`). Es análoga a la variable ``more_to_scan``
 987       presentada en :ref:`dgc_algo_mark`.
 988
 989    *inited*
 990       indica si el recolector fue inicializado.
 991
 992    *stackBottom*
 993       puntero a la base del *stack* (asumiendo que el stack crece hacia arriba).
 994       Se utiliza para saber por donde comenzar a visitar el *stack* de forma
 995       conservativa, tomándolo con una raíz del recolector.
 996
 997    *Pools* (*pooltable*, *npools*)
 998       arreglo variable de punteros a estructuras ``Pool`` (ver más adelante).
 999       Este arreglo se mantiene siempre ordenado de menor a mayor según la
1000       dirección de memoria de la primera página que almacena.
1001
1002    *bucket*
1003       listas de libres. Es un arreglo de estructuras ``List`` utilizadas para
1004       guardar la listas de libres de todos los tamaños de bloques posibles (ver
1005       más adelante).
1006
1007 Atributos que cambian el comportamiento
1008    *noStack*
1009       indica que no debe tomarse al *stack* como raíz del recolector. Esto es
1010       muy poco seguro y no debería ser utilizado nunca, salvo casos
1011       extremadamente excepcionales.
1012
1013    *log*
1014       indica si se debe guardar un registro de la actividad del recolector. Es
1015       utilizado principalmente para depuración.
1016
1017    *disabled*
1018       indica que no se deben realizar recolecciones implícitamente. Si al
1019       tratar de asignar memoria no se puede hallar celdas libres en el *heap*
1020       del recolector, se pide más memoria al sistema operativo sin correr una
1021       recolección para intentar recuperar espacio. Esto es particularmente
1022       útil para secciones de un programa donde el rendimiento es crítico y no
1023       se pueden tolerar grandes pausas como las que puede provocar el
1024       recolector.
1025
1026 Optimizaciones
1027    *p_cache*, *size_cache*
1028       obtener el tamaño de un bloque dado un puntero es una tarea costosa
1029       y común. Para evitarla en casos donde se calcula de forma sucesiva el
1030       tamaño del mismo bloque (como puede ocurrir al concatenar arreglos
1031       dinámicos) se guarda el último calculado en estas variables a modo de
1032       *caché*.
1033
1034    *minAddr*, *maxAddr*
1035       punteros al principio y fin del *heap*. Pueden haber *huecos* entre
1036       estos dos punteros que no pertenezcan al *heap* pero siempre se cumple
1037       que si un puntero apunta al *heap* debe estar en este rango. Esto es
1038       útil para hacer un cálculo rápido para descartar punteros que fueron
1039       tomados de forma conservativa y en realidad no apuntan al *heap* (ver la
1040       función ``find_block()`` en :ref:`dgc_algo_mark`).
1041
1042
1043 *Pools*
1044 ^^^^^^^
1045 La primera diferencia es como está organizado el *heap*. Si bien la
1046 explicación presentada en la sección :ref:`dgc_org` es correcta, la forma en
1047 la que está implementado no es tan *naïve* como los algoritmos presentados en
1048 :ref:`dgc_algo` sugieren.
1049
1050 El recolector guarda un arreglo variable de estructuras ``Pool``. Cabe
1051 destacar que para implementar el recolector no se pueden utilizar los arreglos
1052 dinámicos de D_ (ver sección :ref:`d_high_level`) dado que éstos utilizan de
1053 forma implícita el recolector de basura, por lo tanto todos los arreglos
1054 variables del recolector se implementan utilizando las funciones de
1055 C ``malloc()``, ``realloc()`` y ``free()`` directamente.
1056
1057
1058 La estructura ``Pool`` está compuesta por los siguientes atributos (ver figura
1059 :vref:`fig:dgc-pool`):
1060
1061 .. fig:: fig:dgc-pool
1062
1063    Vista gráfica de la estructura de un *pool* de memoria.
1064
1065    .. aafig::
1066       :scale: 120
1067
1068                 /---  "baseAddr"    "ncommitted = i"          "topAddr" ---\
1069                 |                       V                                  |
1070                 |/                      |/                                 |/
1071                 +----  "committed" -----+-------  "no committed" ----------+
1072                /|                      /|                                 /|
1073                 V                       V                                  V
1074                 +--------+--------+-----+--------+-----+-------------------+
1075         páginas |   0    |   0    | ... |   i    | ... |    "npages - 1"   |
1076                 +--------+--------+-----+--------+-----+-------------------+
1077                     A        A      A       A      A           A
1078                     |        |      |       |      |           |
1079                 +--------+--------+-----+--------+-----+-------------------+
1080       pagetable | Bins 0 | Bins 1 | ... | Bins i | ... | "Bins (npages-1)" |
1081                 +--------+--------+-----+--------+-----+-------------------+
1082
1083 *baseAddr* y *topAddr*
1084    punteros al comienzo y fin de la memoria que almacena todas las páginas del
1085    *pool* (*baseAddr* es análogo al atributo *pages* utilizado en las
1086    secciones anteriores para mayor claridad).
1087
1088 *mark*, *scan*, *freebits*, *finals*, *noscan*
1089    conjunto de bits (*bitsets*) para almacenar los indicadores descriptos en
1090    :ref:`dgc_org` para todos los bloques de todas las páginas del *pool*.
1091    *freebits* es análogo a *free* y *finals* a *final* en los atributos
1092    descriptos en las secciones anteriores.
1093
1094 *npages*
1095    cantidad de páginas que contiene este *pool* (fue nombrado
1096    *number_of_pages* en las secciones anteriores para mayor claridad).
1097
1098 *ncommitted*
1099    cantidad de páginas *encomendadas* al sistema operativo (*committed* en
1100    inglés). Este atributo no se mencionó anteriormente porque el manejo de
1101    páginas encomendadas le agrega una complejidad bastante notable al
1102    recolector y es solo una optimización para un sistema operativo en
1103    particular (Microsoft Windows).
1104
1105 *pagetable*
1106    arreglo de indicadores de tamaño de bloque de cada página de este *pool*.
1107    Los indicadores válidos son ``B_16`` a ``B_2048`` (pasando por los valores
1108    posibles de bloque mencionados anteriormente, todos con el prefijo
1109    "``B_``"), ``B_PAGE``, ``B_PAGEPLUS`` (análogo a ``CONTINUATION``),
1110    ``B_UNCOMMITTED`` (valor que tienen las páginas que no fueron encomendadas
1111    aún) y ``B_FREE``.
1112
1113 Como se observa, además de la información particular del *pool* se almacena
1114 toda la información de páginas y bloques enteramente en el *pool* también.
1115 Esto simplifica el manejo de que lo es memoria *pura* del *heap*, ya que queda
1116 una gran porción continua de memoria sin estar intercalada con
1117 meta-información del recolector.
1118
1119 Para poder acceder a los bits de un bloque en particular, se utiliza la
1120 siguiente cuenta para calcular el índice en el *bitset*:
1121
1122 .. math::
1123
1124    index(p) = \frac{p - baseAddr}{16}
1125
1126 Donde ``p`` es la dirección de memoria del bloque. Esto significa que, sin
1127 importar cual es el tamaño de bloque de las páginas del *pool*, el *pool*
1128 siempre reserva suficientes bits como para que todas las páginas puedan tener
1129 tamaño de bloque de 16 bytes. Esto puede ser desperdiciar bastante espacio si
1130 no predomina un tamaño de bloque pequeño.
1131
1132
1133 Listas de libres
1134 ^^^^^^^^^^^^^^^^
1135 Las listas de libres se almacenan en el recolector como un arreglo de
1136 estructuras ``Lista``, que se compone solamente de un atributo ``List* next``
1137 (es decir, un puntero al siguiente). Entonces cada elemento de ese arreglo es
1138 un puntero al primer elemento de la lista en particular.
1139
1140 La implementación utiliza a los bloques de memoria como nodos directamente.
1141 Como los bloques siempre pueden almacenar una palabra (el bloque de menor
1142 tamaño es de 16 bytes y una palabra ocupa comúnmente entre 4 y 8 bytes según
1143 se trabaje sobre arquitecturas de 32 o 64 bits respectivamente), se almacena
1144 el puntero al siguiente en la primera palabra del bloque.
1145
1146
1147 Algoritmos
1148 ^^^^^^^^^^
1149 Los algoritmos en la implementación real son considerablemente menos modulares
1150 que los presentados en la sección :ref:`dgc_algo`. Por ejemplo, la función
1151 ``collect()`` es una gran función de 300 líneas de código.
1152
1153 A continuación se resumen las funciones principales, separadas en categorías
1154 para facilitar la comprensión. Los siguientes son métodos de la estructura
1155 ``Gcx``:
1156
1157 Inicialización y terminación
1158    *initialize()*
1159       inicializa las estructuras internas del recolector para que pueda ser
1160       utilizado. Esta función la llama la biblioteca *runtime* antes de que el
1161       programa comience a correr.
1162
1163    *Dtor()*
1164        libera todas las estructuras que utiliza el recolector.
1165
1166 Manipulación de raíces definidas por el usuario
1167    *addRoot(p)*, *removeRoot(p)*, *rootIter(dg)*
1168       agrega, remueve e itera sobre las raíces simples definidas por el
1169       usuario.
1170
1171    *addRange(pbot, ptop)*, *remove range(pbot)*, *rangeIter(dg)*
1172       agrega, remueve e itera sobre los rangos de raíces definidas por el
1173       usuario.
1174
1175 Manipulación de indicadores
1176    *getBits(pool, biti)*
1177       obtiene los indicadores especificados para el bloque de índice ``biti``
1178       en el *pool* ``pool``.
1179
1180    *setBits(pool, biti, mask)*
1181       establece los indicadores especificados en ``mask`` para el bloque de
1182       índice ``biti`` en el *pool* ``pool``.
1183
1184    *clrBits(pool, biti, mask)*
1185       limpia los indicadores especificados en ``mask`` para el bloque de
1186       índice ``biti`` en el *pool* ``pool``.
1187
1188    Cada bloque (*bin* en la terminología de la implementación del recolector)
1189    tiene ciertos indicadores asociados. Algunos de ellos pueden ser
1190    manipulados (indirectamente) por el usuario utilizando las funciones
1191    mencionadas arriba.
1192
1193    El parámetro ``mask`` debe ser una máscara de bits que puede estar
1194    compuesta por la conjunción de los siguientes valores:
1195
1196    *FINALIZE*
1197       el objeto almacenado en el bloque tiene un destructor (indicador
1198       *finals*).
1199
1200    *NO_SCAN*
1201       el objeto almacenado en el bloque no contiene punteros (indicador
1202       *noscan*).
1203
1204    *NO_MOVE*
1205       el objeto almacenado en el bloque no debe ser movido [#dgcmove]_.
1206
1207 .. [#dgcmove] Si bien el recolector actual no tiene la capacidad de mover
1208    objetos, la interfaz del recolector hacer que sea posible una
1209    implementación que lo haga, ya que a través de este indicador se pueden
1210    fijar objetos apuntados desde algún segmento no conservativo (objeto
1211    *pinned*).
1212
1213 Búsquedas
1214    *findPool(p)*
1215       busca el *pool* al que pertenece el objeto apuntado por ``p``.
1216
1217    *findBase(p)*
1218       busca la dirección base (el inicio) del bloque apuntado por ``p``
1219       (``find_block()`` según la sección :ref:`dgc_algo_mark`).
1220
1221    *findSize(p)*
1222       busca el tamaño del bloque apuntado por ``p``.
1223
1224    *getInfo(p)*
1225       obtiene información sobre el bloque apuntado por ``p``. Dicha
1226       información se retorna en una estructura ``BlkInfo`` que contiene los
1227       siguientes atributos: ``base`` (dirección del inicio del bloque),
1228       ``size`` (tamaño del bloque) y ``attr`` (atributos o indicadores del
1229       bloque, los que se pueden obtener con ``getBits()``).
1230
1231    *findBin(size)*
1232       calcula el tamaño de bloque más pequeño que pueda contener un objeto de
1233       tamaño ``size`` (``find_block_size()`` según lo visto en
1234       :ref:`dgc_algo_alloc`).
1235
1236 Asignación de memoria
1237    *reserve(size)*
1238       reserva un nuevo *pool* de al menos ``size`` bytes. El algoritmo nunca
1239       crea un *pool* con menos de 256 páginas (es decir, 1 MiB).
1240
1241    *minimize()*
1242       minimiza el uso de la memoria retornando *pools* sin páginas usadas al
1243       sistema operativo.
1244
1245    *newPool(n)*
1246       reserva un nuevo *pool* con al menos ``n`` páginas. Junto con
1247       ``Pool.initialize()`` es análoga a ``new_pool()``, solo que esta función
1248       siempre incrementa el número de páginas a, al menos, 256 páginas (es
1249       decir, los *pools* son siempre mayores a 1 MiB). Si la cantidad de
1250       páginas pedidas supera 256, se incrementa el número de páginas en un 50%
1251       como para que sirva para futuras asignaciones también. Además a medida
1252       que la cantidad de *pools* crece, también trata de obtener cada vez más
1253       memoria. Si ya había un *pool*, el 2do tendrá como mínimo 2 MiB, el 3ro
1254       3 MiB y así sucesivamente hasta 8 MiB. A partir de ahí siempre crea
1255       *pools* de 8 MiB o la cantidad pedida, si ésta es mayor.
1256
1257    *Pool.initialize(n_pages)*
1258       inicializa un nuevo *pool* de memoria. Junto con ``newPool()`` es
1259       análoga a ``new_pool()``. Mientras ``newPool()`` es la encargada de
1260       calcular la cantidad de páginas y crear el objeto *pool*, esta función
1261       es la que pide la memoria al sistema operativo. Además inicializa los
1262       conjuntos de bits: ``mark``, ``scan``, ``freebits``, ``noscan``.
1263       ``finals`` se inicializa de forma perezosa, cuando se intenta asignar el
1264       atributo ``FINALIZE`` a un bloque, se inicializa el conjunto de bits
1265       ``finals`` de todo el *pool*.
1266
1267    *allocPage(bin)*
1268       asigna a una página libre el tamaño de bloque ``bin`` y enlaza los
1269       nuevos bloques libres a la lista de libres correspondiente (análogo
1270       a ``assign_page()``).
1271
1272    *allocPages(n)*
1273       Busca ``n`` cantidad de páginas consecutivas libres (análoga
1274       a ``find_pages(n)``).
1275
1276    *malloc(size, bits)*
1277       asigna memoria para un objeto de tamaño ``size`` bytes. Análoga al
1278       algoritmo ``new(size, attr)`` presentado, excepto que introduce además
1279       un caché para no recalcular el tamaño de bloque necesario si se realizan
1280       múltiples asignaciones consecutivas de objetos del mismo tamaño y que la
1281       asignación de objetos pequeños no está separada en una función aparte.
1282
1283    *bigAlloc(size)*
1284       asigna un objeto grande (análogo a ``new_big()``). La implementación es
1285       mucho más compleja que la presentada en ``new_big()``, pero la semántica
1286       es la misma. La única diferencia es que esta función aprovecha que
1287       ``fullcollectshell()`` / ``fullcollect()`` retornan la cantidad de
1288       páginas liberadas en la recolección por lo que puede optimizar levemente
1289       el caso en que no se liberaron suficientes páginas para asignar el
1290       objeto grande y pasar directamente a crear un nuevo *pool*.
1291
1292    *free(p)*
1293       libera la memoria apuntada por ``p`` (análoga a ``delete()`` de la
1294       sección anterior).
1295
1296    Recordar que la ``pooltable`` siempre se mantiene ordenada según la
1297    dirección de la primera página.
1298
1299 Recolección
1300    *mark(pbot, ptop)*
1301       marca un rango de memoria. Este método es análogo al ``mark_range()``
1302       presentado en la sección :ref:`dgc_algo_mark`.
1303
1304    *fullcollectshell()*
1305       guarda los registros en el *stack* y llama a ``fullcollect()``. El
1306       algoritmo presentado en :ref:`dgc_algo_mark` es simbólico, ya que si los
1307       registros se apilaran en el *stack* dentro de otra función, al salir de
1308       esta se volverían a des-apilar, por lo tanto debe ser hecho en la misma
1309       función ``collect()`` o en una función que luego la llame (como en este
1310       caso).
1311
1312    *fullcollect(stackTop)*
1313       realiza la recolección de basura. Es análoga a ``collect()`` pero es
1314       considerablemente menos modular, todos los pasos se hacen directamente
1315       en esta función: marcado del *root set*, marcado iterativo del *heap*,
1316       barrido y reconstrucción de la lista de libres. Además devuelve la
1317       cantidad de páginas que se liberaron en la recolección, lo que permite
1318       optimizar levemente la función ``bigAlloc()``.
1319
1320
1321 Finalización
1322 ^^^^^^^^^^^^
1323 El recolector actual, por omisión, solamente efectúa una recolección al
1324 finalizar. Por lo tanto, no se ejecutan los destructores de todos aquellos
1325 objetos que son alcanzables desde el *root set* en ese momento. Existe la
1326 opción de no realizar una recolección al finalizar el recolector, pero no de
1327 finalizar *todos* los objetos (alcanzables o no desde el *root set*). Si bien
1328 la especificación de D_ permite este comportamiento (de hecho la
1329 especificación de D_ es tan vaga que permite un recolector que no llame jamás
1330 a ningún destructor), para el usuario puede ser una garantía muy débil
1331 y proveer finalización asegurada puede ser muy deseable.
1332
1333
1334 .. _dgc_committed:
1335
1336 Memoria *encomendada*
1337 ^^^^^^^^^^^^^^^^^^^^^
1338 El algoritmo actual divide un *pool* en dos áreas: memoria *encomendada*
1339 (*committed* en inglés) y *no-encomendada*. Esto se debe a que originalmente
1340 el compilador de D_ DMD_ solo funcionaba en Microsoft Windows y este sistema
1341 operativo puede asignar memoria en dos niveles. Por un lado puede asignar al
1342 proceso un espacio de memoria (*address space*) pero sin asignarle la memoria
1343 correspondiente. En un paso posterior se puede *encomendar* la memoria (es
1344 decir, asignar realmente la memoria).
1345
1346 Para aprovechar esta característica el recolector diferencia estos dos
1347 niveles. Sin embargo, esta diferenciación introduce una gran complejidad (que
1348 se omitió en las secciones anteriores para facilitar la comprensión),
1349 y convierte lo que es una ventaja en un sistema operativo en una desventaja
1350 para todos los demás (ya que los cálculos extra se realizan pero sin ningún
1351 sentido). De hecho hay sistemas operativos, como Linux_, que realizan este
1352 trabajo automáticamente (la memoria no es asignada realmente al programa hasta
1353 que el programa no haga uso de ella; esta capacidad se denomina *overcommit*).
1354
1355 Como se vio en la figura :vref:`fig:dgc-pool`, lás páginas de un *pool* se
1356 dividen en *committed* y *uncommitted*. Siempre que el recolector recorre un
1357 *pool* en busca de una página o bloque, lo hace hasta la memoria *committed*,
1358 porque la *uncommitted* es como si jamás se hubiera pedido al sistema
1359 operativo a efectos prácticos. Además, al buscar páginas libres, si no se
1360 encuentran entre las *encomendadas* se intenta primero *encomendar* páginas
1361 nuevas antes de crear un nuevo *pool*.
1362
1363
1364 Sincronización
1365 ^^^^^^^^^^^^^^
1366 Si bien el recolector no es paralelo ni concurrente (ver :ref:`gc_art`),
1367 soporta múltiples *mutator*\ s. La forma de implementarlo es la más simple.
1368 Todas las operaciones sobre el recolector que se llaman externamente están
1369 sincronizadas utilizando un *lock* global (excepto cuando hay un solo hilo
1370 *mutator*, en cuyo caso se omite la sincronización). Esto afecta también a la
1371 asignación de memoria.
1372
1373
1374
1375 .. _dgc_good:
1376
1377 Características destacadas
1378 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1379
1380 Si bien el recolector en términos generales no se aleja mucho de un
1381 :ref:`marcado y barrido clásico <gc_mark_sweep>`, tiene algunas mejoras por
1382 sobre el algoritmo más básicos que vale la pena destacar:
1383
1384
1385 Organización del *heap*
1386 ^^^^^^^^^^^^^^^^^^^^^^^
1387 El *heap* está organizado de una forma que, si bien no emplea las técnicas más
1388 modernas que pueden observarse en el estado del arte (como :ref:`regiones
1389 <gc_free_list>`), es relativamente sofisticada. El esquema de *pools*
1390 y bloques permite disminuir considerablemente los problemas de *fragmentación*
1391 de memoria y evita búsquedas de *huecos* que pueden ser costosas (como
1392 *best-fit* [#dgcbestfit]_) o desperdiciar mucho espacio (como *first-fit*
1393 [#dgcfirstfit]_), logrando un buen equilibrio entre velocidad y espacio
1394 desperdiciado.
1395
1396 .. [#dgcbestfit] Las búsquedas de tipo *best-fit* son aquellas donde se busca
1397    el *hueco* en el *heap* (es decir, una región contínua de memoria
1398    libre) que mejor se ajuste al tamaño del objeto a asignar. Es decir, el
1399    *hueco* más pequeño lo suficientemente grande como para almacenarlo.
1400
1401 .. [#dgcfirstfit] Las búsquedas de tipo *first-fit* son aquellas donde se busca
1402    el primer *hueco* en el *heap* (es decir, una región contínua de memoria
1403    libre) que sea lo suficientemente grande como para almacenar el objeto
1404    a asignar.
1405
1406
1407 Fase de marcado iterativa
1408 ^^^^^^^^^^^^^^^^^^^^^^^^^
1409 A diferencia del algoritmo clásico recursivo, el algoritmo del recolector
1410 actual es iterativo. El algoritmo recursivo tiene un problema fundamental: se
1411 puede llegar a un desbordamiento de pila (o *stack overflow*). La cantidad de
1412 recursiones necesarias es, en el peor caso, :math:`O(|Live \thickspace set|)`
1413 (por ejemplo, si todas las celdas del *heap* formaran una lista simplemente
1414 enlazada). Hay muchas técnicas para lidiar con este problema, algunas que
1415 podrían aplicarse a D_ y otras que no (como *pointer reversal*) [JOLI96]_. El
1416 recolector actual, sin embargo, cambia complejidad en espacio por complejidad
1417 en tiempo, utilizando un algoritmo iterativo que es constante (:math:`O(1)`)
1418 en espacio, pero que requiere varias pasada sobre el *heap* en vez de una (la
1419 cantidad de pasadas es en el peor caso, al igual que la cantidad de
1420 recursiones del algoritmo recursivo, :math:`O(|Live \thickspace set|)`, pero
1421 cada pasada se realiza por sobre todo el *heap*).
1422
1423
1424 Conjuntos de bits para indicadores
1425 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1426 El algoritmo clásico propone almacenar en la propia celda la marca (para la
1427 fase de marcado) y otros indicadores. El algoritmo del recolector actual
1428 utiliza conjuntos de bits. Esto trae dos ventajas principales:
1429
1430 * Permite minimizar el espacio requerido, ya que de otra forma en general se
1431   desperdicia una palabra entera como cabecera de celda para guardar este tipo
1432   de información.
1433
1434 * Mejora la localidad de referencia, ya que los indicadores se escriben de
1435   forma muy compacta y en una región de memoria contigua que generalmente
1436   puede entrar en el cache o en pocas páginas de memoria acelerando
1437   considerablemente la fase de marcado.
1438
1439
1440 .. _dgc_debug:
1441
1442 Herramientas para depuración
1443 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1444
1445 El recolector provee algunas opciones para simplificar el diagnóstico
1446 y depuración de problemas, tanto del mismo recolector como del programa del
1447 usuario.
1448
1449 Las opciones más importantes son:
1450
1451
1452 ``MEMSTOMP``
1453    Su función es escribir un patrón determinado de bits en todos los bytes de
1454    un bloque de memoria según se haya:
1455
1456    * Pedido un bloque menor a una página (``0xF0``).
1457    * Pedido un bloque mayor a una página (``0xF1``).
1458    * Dejado de usar debido a un pedido de achicamiento de un bloque
1459      (``0xF2``).
1460    * Pedido más páginas debido a un pedido de agrandamiento de un bloque
1461      (``0xF0``).
1462    * Liberado intencionalmente por el usuario (``0xF2``).
1463    * Barrido (``0xF3``).
1464
1465    Esto permite al diagnosticar un problema saber, por ejemplo, si un
1466    determinado área de memoria fue recolectada recientemente, o liberada por
1467    el usuario, o recién adquirida, etc. con tan solo ver si un patrón de bits
1468    determinado está presente. Por supuesto puede existir *falsos positivos*
1469    pero su probabilidad es lo suficientemente baja como para que sea útil en
1470    la práctica.
1471
1472 ``SENTINEL``
1473    Su función detectar errores producidos por escribir más allá (o antes) del
1474    área de memoria solicitada y está implementado reservando un poco más de
1475    memoria de la que pide el usuario, devolviendo un puntero a un bloque
1476    ubicado dentro del bloque real reservado (en vez de al inicio) y finalmente
1477    escribiendo un patrón de bits en los extremos del borde real (ver figura
1478    :vref:`fig:sentinel`), de forma de poder verificar en distintas situación
1479    (por ejemplo al barrer el bloque) que esas áreas de más con los patrones de
1480    bits estén intactas. Esto permite detectar de forma temprana errores tanto
1481    en el recolector como en el programa del usuario.
1482
1483    .. fig:: fig:sentinel
1484
1485       Esquema de un bloque cuando está activada la opción ``SENTINEL``.
1486
1487       .. aafig::
1488          :textual:
1489
1490          |              |              |                              |        |
1491          +-- Palabra ---+-- Palabra ---+-- Tamaño bloque de usuario --+- Byte -+
1492          |              |              |                              |        |
1493
1494          +--------------+--------------+------------------------------+--------+
1495          | "Tamaño del" |     Pre      |                              |  Post  |
1496          |  "bloque de" |              |      Bloque de usuario       |        |
1497          |   "usuario"  |  0xF4F4F4F4  |                              |  0xF5  |
1498          +--------------+--------------+------------------------------+--------+
1499                                        A
1500                                        |
1501                    Puntero devuleto ---/
1502
1503 Ambas opciones son seleccionables sólo en tiempo de compilación del
1504 recolector, por lo que su utilidad real, al menos para el usuario, se ve
1505 severamente reducida.
1506
1507
1508 .. _dgc_bad:
1509
1510 Problemas y limitaciones
1511 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1512
1513 A continuación se presentan los principales problemas encontrados en la
1514 implementación actual del recolector de basura de D_. Estos problemas surgen
1515 principalmente de la observación del código y de aproximadamente tres años de
1516 participación y observación del grupo de noticias, de donde se obtuvieron los
1517 principales problemas percibidos por la comunidad que utiliza el lenguaje.
1518
1519
1520 .. _dgc_bad_code:
1521
1522 Complejidad del código y documentación
1523 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1524 El análisis del código fue muy complicado debido a la falta de documentación
1525 y desorganización del código. Además se nota que el recolector ha sido escrito
1526 en una fase muy temprana y que a ido evolucionando a partir de ello de forma
1527 descuidada y sin ser rescrito nunca para aprovechar las nuevas características
1528 que el lenguaje fue incorporando (por ejemplo *templates*).
1529
1530 Estos dos problemas (código complicado y falta de documentación) producen un
1531 efecto de círculo vicioso, porque provocan que sea complejo entender el
1532 recolector actual y en consecuencia sea muy complicado escribir documentación
1533 o mejorarlo. Esto a su vez provoca que, al no disponer de una implementación
1534 de referencia sencilla, sea muy difícil implementar un recolector nuevo.
1535
1536 .. highlight:: d
1537
1538 Este es, probablemente, la raíz de todos los demás problemas del recolector
1539 actual. Para ilustrar la dimensión del problema se presenta la implementación
1540 real de la función ``bigAlloc()``::
1541
1542     /**
1543      * Allocate a chunk of memory that is larger than a page.
1544      * Return null if out of memory.
1545      */
1546     void *bigAlloc(size_t size)
1547     {
1548         Pool*  pool;
1549         size_t npages;
1550         size_t n;
1551         size_t pn;
1552         size_t freedpages;
1553         void*  p;
1554         int    state;
1555
1556         npages = (size + PAGESIZE - 1) / PAGESIZE;
1557
1558         for (state = 0; ; )
1559         {
1560             // This code could use some refinement when repeatedly
1561             // allocating very large arrays.
1562
1563             for (n = 0; n < npools; n++)
1564             {
1565                 pool = pooltable[n];
1566                 pn = pool.allocPages(npages);
1567                 if (pn != OPFAIL)
1568                     goto L1;
1569             }
1570
1571             // Failed
1572             switch (state)
1573             {
1574             case 0:
1575                 if (disabled)
1576                 {   state = 1;
1577                     continue;
1578                 }
1579                 // Try collecting
1580                 freedpages = fullcollectshell();
1581                 if (freedpages >= npools * ((POOLSIZE / PAGESIZE) / 4))
1582                 {   state = 1;
1583                     continue;
1584                 }
1585                 // Release empty pools to prevent bloat
1586                 minimize();
1587                 // Allocate new pool
1588                 pool = newPool(npages);
1589                 if (!pool)
1590                 {   state = 2;
1591                     continue;
1592                 }
1593                 pn = pool.allocPages(npages);
1594                 assert(pn != OPFAIL);
1595                 goto L1;
1596             case 1:
1597                 // Release empty pools to prevent bloat
1598                 minimize();
1599                 // Allocate new pool
1600                 pool = newPool(npages);
1601                 if (!pool)
1602                     goto Lnomemory;
1603                 pn = pool.allocPages(npages);
1604                 assert(pn != OPFAIL);
1605                 goto L1;
1606             case 2:
1607                 goto Lnomemory;
1608             default:
1609                 assert(false);
1610             }
1611         }
1612
1613       L1:
1614         pool.pagetable[pn] = B_PAGE;
1615         if (npages > 1)
1616             cstring.memset(&pool.pagetable[pn + 1], B_PAGEPLUS, npages - 1);
1617         p = pool.baseAddr + pn * PAGESIZE;
1618         cstring.memset(cast(char *)p + size, 0, npages * PAGESIZE - size);
1619         debug (MEMSTOMP) cstring.memset(p, 0xF1, size);
1620         //debug(PRINTF) printf("\tp = %x\n", p);
1621         return p;
1622
1623       Lnomemory:
1624         return null; // let mallocNoSync handle the error
1625     }
1626
1627 Se recuerda que la semántica de dicha función es la misma que la de la función
1628 ``new_big()`` presentada en :ref:`dgc_algo_alloc`.
1629
1630 Además, como se comentó en la sección anterior, los algoritmos en la
1631 implementación real son considerablemente menos modulares que los presentados
1632 en la sección :ref:`dgc_algo`. Por ejemplo, la función ``fullcollect()`` son
1633 300 líneas de código.
1634
1635
1636 Memoria *encomendada*
1637 ^^^^^^^^^^^^^^^^^^^^^
1638 Como se comentó en la sección anterior, diferenciar entre memoria
1639 *encomendada* de memoria *no-encomendada* es complejo y levemente costoso (en
1640 particular para sistemas operativos que no hacen esta distinción, al menos
1641 explícitamente, donde no hay ningún beneficio en realizar esta distinción).
1642
1643 Incluso para Microsoft Windows, la ventaja de realizar esta distinción es
1644 discutible.
1645
1646
1647 Precisión
1648 ^^^^^^^^^
1649 Este fue históricamente uno de los problemas principales del recolector de D_
1650 [NGD46407]_ [NGD35364]_. Sin embargo, desde que, en la versión 1.001, se ha
1651 incorporado la capacidad de marcar un bloque como de datos puros (no contiene
1652 punteros, el atributo ``NO_SCAN``) [NGA6842]_, la gravedad de esos problemas ha
1653 disminuido considerablemente, aunque siguieron reportándose problemas más
1654 esporádicamente [NGD54084]_ [NGL13744]_.
1655
1656 De todas maneras queda mucho lugar para mejoras, y es un tema recurrente en el
1657 grupo de noticias de D_ y se han discutido formas de poder hacer que, al menos
1658 el *heap* sea preciso [NGD44607]_ [NGD29291]_. Además se mostró un interés
1659 general por tener un recolector más preciso [NGDN87831]_, pero no han habido
1660 avances al respecto.
1661
1662 Otra forma de minimizar los efectos de la falta de precisión que se ha
1663 sugerido reiteradamente en el grupo es teniendo la
1664 posibilidad de indicar cuando no pueden haber punteros interiores a un bloque
1665 [NGD89394]_ [NGD71869]_. Esto puede ser de gran utilidad para objetos grandes
1666 y en particular para mejorar la implementación de de arreglos asociativos.
1667
1668
1669 Referencias débiles
1670 ^^^^^^^^^^^^^^^^^^^
1671 El recolector actual no dispone de soporte de *referencias débiles*
1672 [#dgcweakref]_, sin embargo hay una demanda apreciable [NGD86840]_ [NGD13301]_
1673 [NGL8264]_ [NGD69761]_ [NGD74624]_ [NGD88065]_.
1674
1675 .. [#dgcweakref] Una referencia débil (o *weak reference* en inglés) es
1676    aquella que que no protege al objeto referenciado de ser reciclado por el
1677    recolector.
1678
1679 Para cubrir esta demanda, se han implementado soluciones como biblioteca para
1680 suplir la inexistencia de una implementación oficial [NGA9103]_.
1681
1682 Sin embargo éstas son en general poco robustas, extremadamente dependientes
1683 de la implementación del recolector y, en general, presentan problemas muy
1684 sutiles [NGD88065]_. Por esta razón se ha discutido la posibilidad de incluir
1685 la implementación de *referencias débiles* como parte del lenguaje
1686 [NGD88559]_.
1687
1688
1689 Concurrencia
1690 ^^^^^^^^^^^^
1691 El soporte actual de concurrencia, en todos sus aspectos, es muy primitivo. El
1692 recolector apenas soporta múltiples *mutators* pero con un nivel de
1693 sincronización excesivo.
1694
1695 Se ha sugerido en el pasado el uso de *pools* y listas de libres específicos
1696 de hilos, de manera de disminuir la contención, al menos para la asignación de
1697 memoria [NGD75952]_ [NGDN87831]_.
1698
1699 Además se ha mostrado un interés por tener un nivel de concurrencia aún mayor
1700 en el recolector, para aumentar la concurrencia en ambientes *multi-core* en
1701 general pero en particular para evitar grandes pausas en programas con
1702 requerimientos de tiempo real, históricamente una de las principales críticas
1703 al lenguaje [NGDN87831]_ [NGL3937]_ [NGD22968]_ [NGA15246]_ [NGD5622]_
1704 [NGD2547]_ [NGD18354]_.
1705
1706
1707 Finalización
1708 ^^^^^^^^^^^^
1709 El recolector actual no garantiza la finalización de objetos. En particular
1710 los objetos no son finalizados (es decir, no se llama a sus destructores)
1711 si aún alcanzables desde el *root set* cuando el programa termina. Cabe
1712 destacar que esto puede darse porque hay una referencia real desde el *root
1713 set* (en cuyo caso queda bajo el control del usuario) pero también, dado que
1714 el *root set* se visita de forma conservativa, se puede deber a un falso
1715 positivo, en cuyo caso la omisión de la finalización queda por completo fuera
1716 del control del usuario (y lo que es aún peor, el usuario no puede ser
1717 siquiera notificado de esta anomalía).
1718
1719 Si bien la especificación de D_ no requiere esta capacidad (de hecho,
1720 rigurosamente hablando la especificación de D_ no garantiza la finalización de
1721 objetos bajo ninguna circunstancia), no hay mayores problemas para implementar
1722 un recolector que de este tipo de garantías [NGD88298]_.
1723
1724 Además los objetos pueden ser finalizados tanto determinísticamente
1725 (utilizando ``delete`` o ``scope``; ver secciones :ref:`d_low_level`
1726 y :ref:`d_dbc`) como no determinísticamente (cuando son finalizados por el
1727 recolector). En el primer caso se puede, por ejemplo, acceder sus atributos
1728 u otra memoria que se conozca *viva*, mientras que en el segundo no. Sin
1729 embargo un destructor no puede hacer uso de esta distinción, haciendo que la
1730 finalización determinística tenga a fines prácticos las mismas restricciones
1731 que la finalización no determinística. Es por esto que se ha sugerido permitir
1732 al destructor distinguir estos dos tipos de finalización [NGD89302]_.
1733
1734
1735 Eficiencia
1736 ^^^^^^^^^^
1737 El rendimiento en general del recolector es una de las críticas frecuentes. Si
1738 bien hay muchos problemas que han sido resueltos, en especial por la inclusión
1739 de un mínimo grado de precisión en la versión 1.001, en la actualidad se
1740 siguen encontrando en el grupo de noticias críticas respecto a esto
1741 [NGD43991]_ [NGD67673]_ [NGD63541]_ [NGD90977]_.
1742
1743 La principal causa del bajo rendimiento del recolector actual es,
1744 probablemente, lo simple de su algoritmo principal de recolección. Más allá de
1745 una organización del *heap* moderadamente apropiada y de utilizar conjuntos de
1746 bits para la fase de marcado, el resto del algoritmo es casi la versión más
1747 básica de marcado y barrido. Hay mucho lugar para mejoras en este sentido.
1748
1749
1750 Configurabilidad
1751 ^^^^^^^^^^^^^^^^
1752 Si bien el recolector actual tiene algunas características configurables,
1753 todas son seleccionables sólo en tiempo de compilación del recolector (no del
1754 programa del usuario), como por ejemplo las opciones descriptas en
1755 :ref:`dgc_debug`. Por lo tanto, a nivel práctico, es como si no tuviera
1756 posibilidad alguna de ser configurado por el usuario, ya que no es parte del
1757 ciclo de desarrollo normal el recompilar el recolector o *runtime* de un
1758 lenguaje.
1759
1760 Dado que es imposible que un recolector sea óptimo para todo tipo de
1761 programas, es muy deseable permitir una configuración de parámetros del
1762 recolector que permitan al usuario ajustarlo a las necesidades particulares de
1763 sus programas.
1764
1765
1766 .. _dgc_bad_ocup:
1767
1768 Factor de ocupación del *heap*
1769 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1770 Otro problema potencialmente importante del recolector actual es que no se
1771 tiene ningún cuidado con respecto a que, luego de una recolección, se haya
1772 recuperado una buena parte del *heap*. Por lo tanto, en casos extremos, el
1773 recolector tiene que hacer una recolección por cada petición de memoria, lo
1774 que es extremadamente ineficiente.
1775
1776 Para evitar esto, habría que usar algún esquema para evaluar cuando una
1777 recolección no fue lo suficientemente *exitosa* y en ese caso pedir más
1778 memoria al sistema operativo.
1779
1780
1781 Detalles
1782 ^^^^^^^^
1783 Finalmente hay varios detalles en la implementación actual que podrían
1784 mejorarse:
1785
1786 Listas de libres
1787    hay 12 listas de libres, como para guardar bloques de tamaño de ``B_16``
1788    a ``B_2048``, ``B_PAGE``, ``B_PAGEPLUS``, ``B_UNCOMMITTED`` y ``B_FREE``;
1789    sin embargo solo tienen sentido los bloques de tamaño ``B_16``
1790    a ``B_2048``, por lo que 4 de esas listas no se utilizan.
1791
1792 Conjuntos de bits para indicadores
1793    los indicadores para la fase de marcado y otras propiedades de un bloque
1794    son almacenados en conjuntos de bits que almacenan los indicadores de todos
1795    los bloques de un *pool*. Si bien se ha mencionado esto como una ventaja,
1796    hay lugar todavía como para algunas mejoras. Como un *pool* tiene páginas
1797    con distintos tamaños de bloque, se reserva una cantidad de bits igual a la
1798    mayor cantidad posible de bloques que puede haber en el *pool*; es decir,
1799    se reserva 1 bit por cada 16 bytes del *pool*. Para un *pool* de 1 MiB
1800    (tamaño mínimo), teniendo en cuenta que se utilizan 5 conjuntos de bits
1801    (``mark``, ``scan``, ``finals``, ``freebits`` y ``noscan``), se utilizan 40
1802    KiB de memoria para conjuntos de bits (un 4% de *desperdicio* si, por
1803    ejemplo, ese *pool* estuviera destinado por completo a albergar un solo
1804    objeto grande; lo que equivaldría al 2560 objetos de 16 bytes
1805    desperdiciados en bits inutilizados).
1806
1807 Repetición de código
1808    Hay algunos fragmentos de código repetidos innecesariamente. Por ejemplo en
1809    varios lugares se utilizan arreglos de tamaño variable que se implementan
1810    repetidas veces (en general como un puntero al inicio del arreglo más el
1811    tamaño actual del arreglo más el tamaño de la memoria total asignada
1812    actualmente). Esto es propenso a errores y difícil de mantener.
1813
1814 Uso de señales
1815    el recolector actual utiliza las señales del sistema operativo ``SIGUSR1``
1816    y ``SIGUSR2`` para pausar y reanudar los hilos respectivamente. Esto
1817    puede traer inconvenientes a usuarios que desean utilizar estas
1818    señales en sus programas (o peor aún, si interactúan con bibliotecas
1819    de C que hacen uso de estas señales) [NGD5821]_.
1820
1821 Marcado iterativo
1822    si bien esto se mencionó como algo bueno del recolector actual, es un
1823    compromiso entre tiempo y espacio, y puede ser interesante analizar otros
1824    métodos para evitar la recursión que no requieran tantas pasadas sobre el
1825    *heap*.
1826
1827
1828
1829 .. Esto sería muy similar a la sección de "Recolección de basura) pero en
1830    vez de ir describiendo los algoritmos iría comentando por qué los tomo
1831    o descarto
1832    ESTADO: INCOMPLETO
1833
1834
1835 .. _dgc_via:
1836
1837 Análisis de viabilidad
1838 ----------------------------------------------------------------------------
1839
1840 Ya conociendo el lenguaje de programación D_ (con sus necesidades
1841 particulares), el estado del arte en recolección de basura  y el recolector
1842 actual de D_ es posible evaluar la viabilidad de los distintos algoritmos
1843 vistos en el capítulo :ref:`gc`. Se recuerda que dentro del análisis de
1844 viabilidad de considera de gran importancia la viabilidad social y política de
1845 la mejora, es decir, se presta particular atención en encontrar una mejora que
1846 tenga una buena probabilidad de ser aceptada por la comunidad de D_.
1847
1848
1849 .. _dgc_via_classic:
1850
1851 Algoritmos clásicos
1852 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1853
1854 En esta sección se presenta un análisis de los :ref:`algoritmos clásicos
1855 <gc_classic>`, de forma de poder analizar a grandes rasgos las principales
1856 familias para ir determinando la dirección principal de la solución.
1857
1858
1859 .. _dgc_via_rc:
1860
1861 Conteo de referencias
1862 ^^^^^^^^^^^^^^^^^^^^^
1863 Ya se ha propuesto en el pasado la utilización de conteo de referencias en D_
1864 pero no se ha demostrado un interés real, más allá de soluciones en
1865 bibliotecas [NGD38689]_. Las razones para no utilizar conteo de referencia son
1866 más o menos las mismas que las desventajas mencionadas en la sección
1867 :ref:`gc_rc` (en el capítulo :ref:`gc`), siendo la principal la incapacidad de
1868 recolectar ciclos. Sin embargo hay otras razones importantes.
1869
1870 Una de ellas es la inter-operatividad con C. El utilizar un contador de
1871 referencias requiere la manipulación del contador por parte del código C con
1872 el que se interactúe. Si bien este problema ya está presente si código
1873 C guarda un puntero a un objeto almacenado en el *heap* del recolector de D_
1874 en el *heap* de C (es decir, en una celda de memoria asignada por
1875 ``malloc()``), esto es poco común. Sin embargo, mientras que una función de
1876 C se está ejecutando, es extremadamente común que pueda almacenar en el
1877 *stack* una referencia a un objeto de D_ y en ese caso el recolector actual
1878 puede manejarlo (mientras la función de C esté corriendo en un hilo creado por
1879 D_). Sin embargo al usar un conteo de referencias esto es más problemático, ya
1880 que no se mantiene la invariante del algoritmo si no son actualizados siempre
1881 los contadores.
1882
1883 Otro problema es que al liberarse una celda, existe la posibilidad de tener
1884 que liberar todo el sub-grafo conectado a ésta. Cuando este sub-grafo es
1885 grande, se puede observar una gran pausa.
1886
1887 Si bien estas razones son suficientes como para considerar que el conteo de
1888 referencias no es un algoritmo que sea viable en D_, hay muchas técnicas
1889 y optimizaciones para minimizarlas (como liberación perezosa, conteo de
1890 referencias pospuesto, etc. [JOLI96]_). Sin embargo hay otra razón importante
1891 que descarta esta familia de algoritmos ya que todas las variaciones de conteo
1892 de referencias implican, en mayor o menor medida, el entrelazado del trabajo
1893 del recolector con el del *mutator*. Si bien esta es una característica en
1894 general muy deseable (porque hace que el recolector sea :ref:`incremental
1895 <gc_inc>`), en D_ no lo es porque tiene como requerimiento no hacer pagar el
1896 precio de cosas que no se usan. En D_ debe ser posible no utilizar el
1897 recolector de basura y, al no hacerlo, no tener ningún tipo de trabajo extra
1898 asociado a éste. De usarse conteo de referencias esto no sería posible.
1899
1900 Si bien este requerimiento puede ser discutible técnicamente, hay una gran
1901 resistencia social y política ante cualquier tipo de recolector que imponga
1902 una penalización de rendimiento a alguien que no quiera usarlo [NGD38689]_.
1903 Además requiere un cambio complejo y profundo en el compilador, siendo éste
1904 uno de los eslabones con mayor resistencia a introducir cambios.
1905
1906 Por lo tanto se concluye que el conteo de referencias no es un algoritmo
1907 viable para este trabajo.
1908
1909
1910 .. _dgc_via_mark_sweep:
1911
1912 Marcado y barrido
1913 ^^^^^^^^^^^^^^^^^
1914 El marcado y barrido es un algoritmo evidentemente viable debido a que es la
1915 base del algoritmo del recolector de basura actual.
1916
1917 En general en la comunidad de D_ no hay mayores críticas al marcado y barrido
1918 en sí, si no más bien a problemas asociados a la implementación actual,
1919 principalmente a las grandes pausas o la falta de :ref:`precisión
1920 <gc_conserv>` [NGD54084]_ [NGL13744]_ [NGD44607]_ [NGD29291]_ [NGDN87831]_
1921 [NGDN87831]_ [NGL3937]_ [NGD22968]_ [NGA15246]_ [NGD5622]_ [NGD2547]_
1922 [NGD18354]_.
1923
1924 Esta familia de algoritmos se adapta bien a los requerimientos principales de
1925 D_ en cuanto a recolección de basura (ver :ref:`dgc_needs`), por ejemplo
1926 permite recolectar de forma conservativa, no impone un *overhead* a menos que
1927 se utilice el recolector, permite liberar memoria manualmente, se adapta de
1928 forma simple para soportar punteros *interiores* y permite finalizar objetos
1929 (con las limitaciones mencionadas en :ref:`dgc_prob_final`).
1930
1931 Sin embargo muchas de las limitaciones del recolector actual (ver
1932 :ref:`dgc_bad`), no son inherentes al marcado y barrido, por lo que aún
1933 conservando la base del algoritmo, es posible realizar una cantidad de mejoras
1934 considerable.
1935
1936 Una de las principales mejoras que pueden realizarse es hacer al recolector
1937 :ref:`concurrente <gc_concurrent>` y parcialmente más :ref:`preciso
1938 <gc_conserv>`. Estas dos mejoras solamente alcanzarían para mejorar de forma
1939 notable el tiempo de pausa en las recolecciones y la cantidad de memoria
1940 retenida debido a falsos positivos.
1941
1942 Más adelante veremos detalles sobre algunos de estos aspectos y sobre algunos
1943 algoritmos particulares que permiten hacer concurrente al recolector actual.
1944
1945
1946 Copia de semi-espacio
1947 ^^^^^^^^^^^^^^^^^^^^^
1948 La copia de semi-espacio, al igual que cualquier otro tipo de recolector con
1949 movimiento, requiere (en la mayoría de los casos) disponer de una
1950 :ref:`precisión <gc_conserv>` casi completa. Las celdas para las cuales hay
1951 alguna referencia que no es precisa no pueden ser movidas, ya que al no estar
1952 seguros que la referencia sea tal, ésta no puede ser actualizada con la
1953 dirección de la nueva ubicación de la celda movida porque de no ser una
1954 referencia se estarían alterando datos del usuario, corrompiéndolos.
1955
1956 Es por esto que si el recolector no es mayormente preciso, las celdas que
1957 pueden ser movidas son muy pocas y, por lo tanto, se pierden las principales
1958 ventajas de esta familia de recolectores (como la capacidad de asignar nueva
1959 memoria mediante *pointer bump allocation*).
1960
1961 Este aumento de precisión, sin embargo, es bastante realizable. Es posible, en
1962 teoría, hacer que al menos el *heap* sea preciso, aunque es discutible si en
1963 la práctica es aceptable el *overhead* en espacio necesario para almacenar la
1964 información del tipo de una celda. Esto se analiza en más detalle al evaluar
1965 la recolección precisa en la siguiente sección.
1966
1967 Si bien las principales herramientas para que sea viable un recolector por
1968 copia de semi-espacio están disponibles en D_ (como la posibilidad de hacer
1969 *pinning* the celdas o el potencial incremento de precisión), este lenguaje
1970 nunca va a poder proveer precisión total, haciendo que no sea posible
1971 implementar un recolector por copia de semi-espacio puro. Siempre habrá que
1972 disponer un esquema híbrido para poder manejar las celdas que no puedan
1973 moverse, incrementado mucho la complejidad del recolector.
1974
1975 Si bien un esquema híbrido es algo técnicamente posible, nuevamente la
1976 resistencia social a un cambio de esta envergadura es de importancia
1977 suficiente como para inclinarse por una solución menos drástica.
1978
1979
1980 .. _dgc_via_art:
1981
1982 Principales categorías del estado del arte
1983 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1984
1985 En esta sección se realiza un análisis de la viabilidad de las principales
1986 categorías de recolectores según se presentaron en la sección :ref:`gc_art`.
1987
1988 Recolección directa / indirecta
1989 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1990 Como se ha visto al analizar el conteo de referencias, lo más apropiado para
1991 D_ pareciera ser continuar con el esquema de recolección indirecta, de forma
1992 tal de que el precio de la recolección solo deba ser pagado cuando el
1993 *mutator* realmente necesita del recolector. Es por esto que no parece ser una
1994 opción viable introducir recolección directa en este trabajo.
1995
1996
1997 Recolección incremental
1998 ^^^^^^^^^^^^^^^^^^^^^^^
1999 La recolección incremental puede ser beneficiosa para D_, dado que puede
2000 servir para disminuir el tiempo de pausa del recolector. Sin embargo, en
2001 general es necesario instrumentar el *mutator* para reportar cambios en el
2002 grafo del conectividad al recolector. Además puede contar con los mismos
2003 problemas que la recolección directa, puede hacer que el usuario tenga que
2004 pagar el precio de la recolección, incluso cuando no la necesita, si por cada
2005 asignación el recolector realiza parte de una recolección que no fue
2006 solicitada.
2007
2008 Recolección concurrente / paralela / *stop-the-world*
2009 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2010 El recolector actual es *stop-the-world*, sin embargo esta es una de las
2011 principales críticas que tiene. El recolector se podría ver beneficiado de
2012 recolección paralela, tanto para realizar la recolección más velozmente en
2013 ambientes multi-procesador, como para disminuir el tiempo de pausa. Sin
2014 embargo, el hecho de que todos los hilos se pausen para realizar parte del
2015 trabajo del recolector puede ser contraproducente para programas *real-time*
2016 que pretendan usar un hilo que no sufra de la latencia del recolector,
2017 asegurando que nunca lo use (aunque se podrían ver esquemas para ajustarse
2018 a estas necesidades).
2019
2020 En general los recolectores concurrentes necesitan también instrumentar el
2021 *mutator* para reportar cambios en el grafo de conectividad al recolector,
2022 como sucede con la recolección directa o incremental, sin embargo hay
2023 algoritmos que no tienen este requerimiento, utilizando servicios del sistema
2024 operativo para tener una *fotografía* de la memoria para que la fase de
2025 marcado pueda realizarse sin perturbar al *mutator* ni requerir de su
2026 cooperación [RODR97]_. Este tipo de algoritmos serían un buen candidato para
2027 D_, dado que requiere pocos cambios y es transparente al *mutator*.
2028
2029
2030 Recolección conservativa / precisa
2031 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2032 Si bien D_ puede proveer al recolector de basura información de tipos para los
2033 objetos almacenados en el *heap*, todo recolector para D_ deberá soportar
2034 cierto grado de recolección conservativa (ver :ref:`gc_conserv`), debido a las
2035 siguientes razones:
2036
2037 * Si bien D_ podría incorporar información de tipos para el *stack*
2038   (utilizando, por ejemplo, la técnica de *shadow stack* [HEND02]_), para
2039   poder interactuar con C/C++, el recolector debe poder interpretar los *stack
2040   frames* [#dgcstackframe]_ de estos lenguajes, que no disponen de información
2041   de tipos.
2042
2043 * Los registros del procesador tienen un problema similar, con la diferencia
2044   de que el costo de implementar algo similar a *shadow stack* para los
2045   registros sería impracticable, más allá de que exista la misma limitación
2046   que con el *stack* para poder interactuar con C/C++.
2047
2048 * D_ soporta uniones (ver :ref:`d_low_level`). Para una unión es imposible
2049   determinar si un campo es un puntero o no. Por ejemplo::
2050
2051       union U {
2052          size_t x;
2053          void* p;
2054       }
2055
2056   Aquí el recolector no puede saber nunca si el valor almacenado será un
2057   ``size_t`` o un ``void*``, por lo tanto deberá tratar **siempre** esa
2058   palabra de forma conservativa (es decir, interpretarla como un *posible*
2059   puntero). Este requerimiento puede ser relajado si el usuario proveyera
2060   alguna forma de determinar que tipo está almacenando la unión en un
2061   determinado momento. Sin embargo el costo de pedir al usuario este tipo de
2062   restricción puede ser muy alto.
2063
2064 Sin embargo, ya hay un trabajo relacionado avanzando en este sentido, que
2065 agrega precisión al marcado del *heap*. David Simcha comienza con este trabajo
2066 explorando la posibilidad de agregar precisión parcial al recolector,
2067 generando información sobre la ubicación de los punteros para cada tipo
2068 [DBZ3463]_. Su trabajo se limita a una implementación a nivel biblioteca de
2069 usuario y sobre `D 2.0`_.  Desafortunadamente su trabajo pasa desapercibido
2070 por un buen tiempo.
2071
2072 Sin embargo un tiempo después Vincent Lang (mejor conocido como *wm4* en la
2073 comunidad de D_), retoma este trabajo, pero modificando el compilador DMD_
2074 y trabajando con `D 1.0`_ y Tango_. Es por esto que el aumento de precisión
2075 parece ser un área fértil para este trabajo, en particular si se colabora con
2076 el trabajo realizado por David y Vincent.
2077
2078 .. [#dgcstackframe] Un *stack frame* (*marco de la pila* en castellano),
2079    también conocido como *activation record* (o *registro de activación* en
2080    castellano) es una estructura de datos dependiente de la arquitectura que
2081    contiene información del estado de una función, incluyendo, por ejemplo,
2082    sus variables locales, parámetros y dirección de retorno.
2083
2084
2085 Recolección con movimiento de celdas
2086 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2087 Esta posibilidad ya se ha discutido al analizar la posibilidad de utilizar
2088 recolección con copia de semi-espacios. El trabajo mencionado en la sub-sección
2089 anterior agrega información suficiente como poder diferenciar que celdas se
2090 pueden mover y cuales no, sin embargo queda como incógnita qué proporción de
2091 celdas deben permanecer inmovilizadas como para evaluar si un cambio tan
2092 grande puede rendir frutos o no.
2093
2094 A priori, pareciera que la relación cantidad y complejidad de cambios sobre
2095 beneficios potenciales no fuera muy favorable a esta mejora.
2096
2097
2098 Lista de libres / *pointer bump allocation*
2099 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2100 Como consecuencia de los puntos anteriores, no es técnicamente posible
2101 realizar *pointer bump allocation* pura en D_. Al haber objetos *pinned*,
2102 siempre es necesario o bien contar con una lista de libres, o detectar
2103 *huecos* en un esquema de *pointer bump allocation*. Es por esto que parece
2104 ser más viable conservar el esquema de listas de libres.
2105
2106 Esta mejora también entra en la categoría de opciones viables pero cuya
2107 complejidad no parece valer la pena dada la limitada utilidad que se espera
2108 dadas las particulares características de D_ en cuanto a precisión de
2109 información de tipos de *stack*, uniones, etc.
2110
2111
2112 Recolección por particiones / generacional
2113 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2114 Una vez más la recolección por particiones, en particular la generacional,
2115 requiere de la instrumentación del *mutator* para comunicar cambios en el
2116 grafo de conectividad al recolector, por lo que es poco viable. Aunque existen
2117 algoritmos que no necesitan este tipo de comunicación dado que está
2118 garantizado que no existan conexiones entre celdas de las distintas
2119 particiones, requiere grandes cambios en el compilador y realizar análisis
2120 estático bastante complejo [HIRZ03]_. Además al ser D_ un lenguaje de bajo
2121 nivel, es muy difícil garantizar que estas conexiones inter-particiones no
2122 puedan existir realmente; y de poder lograrlo, podría ser demasiado
2123 restrictivo.
2124
2125
2126 .. include:: links.rst
2127
2128 .. vim: set ts=3 sts=3 sw=3 et tw=78 spelllang=es :