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, CORREGIDO
   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       for pool in heap
 858          all_free = true
 859          for 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 *baseAddr* y *topAddr*
1062    punteros al comienzo y fin de la memoria que almacena todas las páginas del
1063    *pool* (*baseAddr* es análogo al atributo *pages* utilizado en las
1064    secciones anteriores para mayor claridad).
1065
1066 *mark*, *scan*, *freebits*, *finals*, *noscan*
1067    conjunto de bits (*bitsets*) para almacenar los indicadores descriptos en
1068    :ref:`dgc_org` para todos los bloques de todas las páginas del *pool*.
1069    *freebits* es análogo a *free* y *finals* a *final* en los atributos
1070    descriptos en las secciones anteriores.
1071
1072 *npages*
1073    cantidad de páginas que contiene este *pool* (fue nombrado
1074    *number_of_pages* en las secciones anteriores para mayor claridad).
1075
1076 *ncommitted*
1077    cantidad de páginas *encomendadas* al sistema operativo (*committed* en
1078    inglés). Este atributo no se mencionó anteriormente porque el manejo de
1079    páginas encomendadas le agrega una complejidad bastante notable al
1080    recolector y es solo una optimización para un sistema operativo en
1081    particular (Microsoft Windows).
1082
1083 *pagetable*
1084    arreglo de indicadores de tamaño de bloque de cada página de este *pool*.
1085    Los indicadores válidos son ``B_16`` a ``B_2048`` (pasando por los valores
1086    posibles de bloque mencionados anteriormente, todos con el prefijo
1087    "``B_``"), ``B_PAGE``, ``B_PAGEPLUS`` (análogo a ``CONTINUATION``),
1088    ``B_UNCOMMITTED`` (valor que tienen las páginas que no fueron encomendadas
1089    aún) y ``B_FREE``.
1090
1091 .. fig:: fig:dgc-pool
1092
1093    Vista gráfica de la estructura de un *pool* de memoria.
1094
1095    .. aafig::
1096       :scale: 120
1097
1098                 /---  "baseAddr"    "ncommitted = i"          "topAddr" ---\
1099                 |                       V                                  |
1100                 |/                      |/                                 |/
1101                 +----  "committed" -----+-------  "no committed" ----------+
1102                /|                      /|                                 /|
1103                 V                       V                                  V
1104                 +--------+--------+-----+--------+-----+-------------------+
1105         páginas |   0    |   0    | ... |   i    | ... |    "npages - 1"   |
1106                 +--------+--------+-----+--------+-----+-------------------+
1107                     A        A      A       A      A           A
1108                     |        |      |       |      |           |
1109                 +--------+--------+-----+--------+-----+-------------------+
1110       pagetable | Bins 0 | Bins 1 | ... | Bins i | ... | "Bins (npages-1)" |
1111                 +--------+--------+-----+--------+-----+-------------------+
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 Memoria *encomendada*
1335 ^^^^^^^^^^^^^^^^^^^^^
1336 El algoritmo actual divide un *pool* en dos áreas: memoria *encomendada*
1337 (*committed* en inglés) y *no-encomendada*. Esto se debe a que originalmente
1338 el compilador de D_ DMD_ solo funcionaba en Microsoft Windows y este sistema
1339 operativo puede asignar memoria en dos niveles. Por un lado puede asignar al
1340 proceso un espacio de memoria (*address space*) pero sin asignarle la memoria
1341 correspondiente. En un paso posterior se puede *encomendar* la memoria (es
1342 decir, asignar realmente la memoria).
1343
1344 Para aprovechar esta característica el recolector diferencia estos dos
1345 niveles. Sin embargo, esta diferenciación introduce una gran complejidad (que
1346 se omitió en las secciones anteriores para facilitar la comprensión),
1347 y convierte lo que es una ventaja en un sistema operativo en una desventaja
1348 para todos los demás (ya que los cálculos extra se realizan pero sin ningún
1349 sentido). De hecho hay sistemas operativos, como Linux_, que realizan este
1350 trabajo automáticamente (la memoria no es asignada realmente al programa hasta
1351 que el programa no haga uso de ella; esta capacidad se denomina *overcommit*).
1352
1353 Como se vio en la figura :vref:`fig:dgc-pool`, lás páginas de un *pool* se
1354 dividen en *committed* y *uncommitted*. Siempre que el recolector recorre un
1355 *pool* en busca de una página o bloque, lo hace hasta la memoria *committed*,
1356 porque la *uncommitted* es como si jamás se hubiera pedido al sistema
1357 operativo a efectos prácticos. Además, al buscar páginas libres, si no se
1358 encuentran entre las *encomendadas* se intenta primero *encomendar* páginas
1359 nuevas antes de crear un nuevo *pool*.
1360
1361
1362 Sincronización
1363 ^^^^^^^^^^^^^^
1364 Si bien el recolector no es paralelo ni concurrente (ver :ref:`gc_art`),
1365 soporta múltiples *mutator*\ s. La forma de implementarlo es la más simple.
1366 Todas las operaciones sobre el recolector que se llaman externamente están
1367 sincronizadas utilizando un *lock* global (excepto cuando hay un solo hilo
1368 *mutator*, en cuyo caso se omite la sincronización). Esto afecta también a la
1369 asignación de memoria.
1370
1371
1372
1373 .. _dgc_good:
1374
1375 Características destacadas
1376 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1377
1378 Si bien el recolector en términos generales no se aleja mucho de un
1379 :ref:`marcado y barrido clásico <gc_mark_sweep>`, tiene algunas mejoras por
1380 sobre el algoritmo más básicos que vale la pena destacar:
1381
1382
1383 Organización del *heap*
1384 ^^^^^^^^^^^^^^^^^^^^^^^
1385 El *heap* está organizado de una forma que, si bien no emplea las técnicas más
1386 modernas que pueden observarse en el estado del arte (como :ref:`regiones
1387 <gc_free_list>`), es relativamente sofisticada. El esquema de *pools*
1388 y bloques permite disminuir considerablemente los problemas de *fragmentación*
1389 de memoria y evita búsquedas de *huecos* que pueden ser costosas (como
1390 *best-fit* [#dgcbestfit]_) o desperdiciar mucho espacio (como *first-fit*
1391 [#dgcfirstfit]_), logrando un buen equilibrio entre velocidad y espacio
1392 desperdiciado.
1393
1394 .. [#dgcbestfit] Las búsquedas de tipo *best-fit* son aquellas donde se busca
1395    el *hueco* en el *heap* (es decir, una región contínua de memoria
1396    libre) que mejor se ajuste al tamaño del objeto a asignar. Es decir, el
1397    *hueco* más pequeño lo suficientemente grande como para almacenarlo.
1398
1399 .. [#dgcfirstfit] Las búsquedas de tipo *first-fit* son aquellas donde se busca
1400    el primer *hueco* en el *heap* (es decir, una región contínua de memoria
1401    libre) que sea lo suficientemente grande como para almacenar el objeto
1402    a asignar.
1403
1404
1405 Fase de marcado iterativa
1406 ^^^^^^^^^^^^^^^^^^^^^^^^^
1407 A diferencia del algoritmo clásico recursivo, el algoritmo del recolector
1408 actual es iterativo. El algoritmo recursivo tiene un problema fundamental: se
1409 puede llegar a un desbordamiento de pila (o *stack overflow*). La cantidad de
1410 recursiones necesarias es, en el peor caso, :math:`O(|Live \thickspace set|)`
1411 (por ejemplo, si todas las celdas del *heap* formaran una lista simplemente
1412 enlazada). Hay muchas técnicas para lidiar con este problema, algunas que
1413 podrían aplicarse a D_ y otras que no (como *pointer reversal*) [JOLI96]_. El
1414 recolector actual, sin embargo, cambia complejidad en espacio por complejidad
1415 en tiempo, utilizando un algoritmo iterativo que es constante (:math:`O(1)`)
1416 en espacio, pero que requiere varias pasada sobre el *heap* en vez de una (la
1417 cantidad de pasadas es en el peor caso, al igual que la cantidad de
1418 recursiones del algoritmo recursivo, :math:`O(|Live \thickspace set|)`, pero
1419 cada pasada se realiza por sobre todo el *heap*).
1420
1421
1422 Conjuntos de bits para indicadores
1423 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1424 El algoritmo clásico propone almacenar en la propia celda la marca (para la
1425 fase de marcado) y otros indicadores. El algoritmo del recolector actual
1426 utiliza conjuntos de bits. Esto trae dos ventajas principales:
1427
1428 * Permite minimizar el espacio requerido, ya que de otra forma en general se
1429   desperdicia una palabra entera como cabecera de celda para guardar este tipo
1430   de información.
1431
1432 * Mejora la localidad de referencia, ya que los indicadores se escriben de
1433   forma muy compacta y en una región de memoria contigua que generalmente
1434   puede entrar en el cache o en pocas páginas de memoria acelerando
1435   considerablemente la fase de marcado.
1436
1437
1438 .. _dgc_debug:
1439
1440 Herramientas para depuración
1441 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1442
1443 El recolector provee algunas opciones para simplificar el diagnóstico
1444 y depuración de problemas, tanto del mismo recolector como del programa del
1445 usuario.
1446
1447 Las opciones más importantes son:
1448
1449
1450 ``MEMSTOMP``
1451    Su función es escribir un patrón determinado de bits en todos los bytes de
1452    un bloque de memoria según se haya:
1453
1454    * Pedido un bloque menor a una página (``0xF0``).
1455    * Pedido un bloque mayor a una página (``0xF1``).
1456    * Dejado de usar debido a un pedido de achicamiento de un bloque
1457      (``0xF2``).
1458    * Pedido más páginas debido a un pedido de agrandamiento de un bloque
1459      (``0xF0``).
1460    * Liberado intencionalmente por el usuario (``0xF2``).
1461    * Barrido (``0xF3``).
1462
1463    Esto permite al diagnosticar un problema saber, por ejemplo, si un
1464    determinado área de memoria fue recolectada recientemente, o liberada por
1465    el usuario, o recién adquirida, etc. con tan solo ver si un patrón de bits
1466    determinado está presente. Por supuesto puede existir *falsos positivos*
1467    pero su probabilidad es lo suficientemente baja como para que sea útil en
1468    la práctica.
1469
1470 ``SENTINEL``
1471    Su función detectar errores producidos por escribir más allá (o antes) del
1472    área de memoria solicitada y está implementado reservando un poco más de
1473    memoria de la que pide el usuario, devolviendo un puntero a un bloque
1474    ubicado dentro del bloque real reservado (en vez de al inicio) y finalmente
1475    escribiendo un patrón de bits en los extremos del borde real (ver figura
1476    :vref:`fig:sentinel`), de forma de poder verificar en distintas situación
1477    (por ejemplo al barrer el bloque) que esas áreas de más con los patrones de
1478    bits estén intactas. Esto permite detectar de forma temprana errores tanto
1479    en el recolector como en el programa del usuario.
1480
1481    .. fig:: fig:sentinel
1482
1483       Esquema de un bloque cuando está activada la opción ``SENTINEL``.
1484
1485       .. aafig::
1486
1487          |              |              |                              |        |
1488          +-- Palabra ---+-- Palabra ---+-- Tamaño bloque de usuario --+- Byte -+
1489          |              |              |                              |        |
1490
1491          +--------------+--------------+------------------------------+--------+
1492          |  Tamaño del  |     Pre      |                              |  Post  |
1493          |  bloque  de  |              |      Bloque de usuario       |        |
1494          |    usuario   |  0xF4F4F4F4  |                              |  0xF5  |
1495          +--------------+--------------+------------------------------+--------+
1496                                        A
1497                                        |
1498                    Puntero devuleto ---/
1499
1500 Ambas opciones son seleccionables sólo en tiempo de compilación del
1501 recolector, por lo que su utilidad real, al menos para el usuario, se ve
1502 severamente reducida.
1503
1504
1505 .. _dgc_bad:
1506
1507 Problemas y limitaciones
1508 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1509
1510 A continuación se presentan los principales problemas encontrados en la
1511 implementación actual del recolector de basura de D_. Estos problemas surgen
1512 principalmente de la observación del código y de aproximadamente tres años de
1513 participación y observación del grupo de noticias, de donde se obtuvieron los
1514 principales problemas percibidos por la comunidad que utiliza el lenguaje.
1515
1516
1517 .. _dgc_bad_code:
1518
1519 Complejidad del código y documentación
1520 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1521 El análisis del código fue muy complicado debido a la falta de documentación
1522 y desorganización del código. Además se nota que el recolector ha sido escrito
1523 en una fase muy temprana y que a ido evolucionando a partir de ello de forma
1524 descuidada y sin ser rescrito nunca para aprovechar las nuevas características
1525 que el lenguaje fue incorporando (por ejemplo *templates*).
1526
1527 Estos dos problemas (código complicado y falta de documentación) producen un
1528 efecto de círculo vicioso, porque provocan que sea complejo entender el
1529 recolector actual y en consecuencia sea muy complicado escribir documentación
1530 o mejorarlo. Esto a su vez provoca que, al no disponer de una implementación
1531 de referencia sencilla, sea muy difícil implementar un recolector nuevo.
1532
1533 Este es, probablemente, la raíz de todos los demás problemas del recolector
1534 actual. Para ilustrar la dimensión del problema se presenta la implementación
1535 real de la función ``bigAlloc()``::
1536
1537     /**
1538      * Allocate a chunk of memory that is larger than a page.
1539      * Return null if out of memory.
1540      */
1541     void *bigAlloc(size_t size)
1542     {
1543         Pool*  pool;
1544         size_t npages;
1545         size_t n;
1546         size_t pn;
1547         size_t freedpages;
1548         void*  p;
1549         int    state;
1550
1551         npages = (size + PAGESIZE - 1) / PAGESIZE;
1552
1553         for (state = 0; ; )
1554         {
1555             // This code could use some refinement when repeatedly
1556             // allocating very large arrays.
1557
1558             for (n = 0; n < npools; n++)
1559             {
1560                 pool = pooltable[n];
1561                 pn = pool.allocPages(npages);
1562                 if (pn != OPFAIL)
1563                     goto L1;
1564             }
1565
1566             // Failed
1567             switch (state)
1568             {
1569             case 0:
1570                 if (disabled)
1571                 {   state = 1;
1572                     continue;
1573                 }
1574                 // Try collecting
1575                 freedpages = fullcollectshell();
1576                 if (freedpages >= npools * ((POOLSIZE / PAGESIZE) / 4))
1577                 {   state = 1;
1578                     continue;
1579                 }
1580                 // Release empty pools to prevent bloat
1581                 minimize();
1582                 // Allocate new pool
1583                 pool = newPool(npages);
1584                 if (!pool)
1585                 {   state = 2;
1586                     continue;
1587                 }
1588                 pn = pool.allocPages(npages);
1589                 assert(pn != OPFAIL);
1590                 goto L1;
1591             case 1:
1592                 // Release empty pools to prevent bloat
1593                 minimize();
1594                 // Allocate new pool
1595                 pool = newPool(npages);
1596                 if (!pool)
1597                     goto Lnomemory;
1598                 pn = pool.allocPages(npages);
1599                 assert(pn != OPFAIL);
1600                 goto L1;
1601             case 2:
1602                 goto Lnomemory;
1603             default:
1604                 assert(false);
1605             }
1606         }
1607
1608       L1:
1609         pool.pagetable[pn] = B_PAGE;
1610         if (npages > 1)
1611             cstring.memset(&pool.pagetable[pn + 1], B_PAGEPLUS, npages - 1);
1612         p = pool.baseAddr + pn * PAGESIZE;
1613         cstring.memset(cast(char *)p + size, 0, npages * PAGESIZE - size);
1614         debug (MEMSTOMP) cstring.memset(p, 0xF1, size);
1615         //debug(PRINTF) printf("\tp = %x\n", p);
1616         return p;
1617
1618       Lnomemory:
1619         return null; // let mallocNoSync handle the error
1620     }
1621
1622 Se recuerda que la semántica de dicha función es la misma que la de la función
1623 ``new_big()`` presentada en :ref:`dgc_algo_alloc`.
1624
1625 Además, como se comentó en la sección anterior, los algoritmos en la
1626 implementación real son considerablemente menos modulares que los presentados
1627 en la sección :ref:`dgc_algo`. Por ejemplo, la función ``fullcollect()`` son
1628 300 líneas de código.
1629
1630
1631 Memoria *encomendada*
1632 ^^^^^^^^^^^^^^^^^^^^^
1633 Como se comentó en la sección anterior, diferenciar entre memoria
1634 *encomendada* de memoria *no-encomendada* es complejo y levemente costoso (en
1635 particular para sistemas operativos que no hacen esta distinción, al menos
1636 explícitamente, donde no hay ningún beneficio en realizar esta distinción).
1637
1638 Incluso para Microsoft Windows, la ventaja de realizar esta distinción es
1639 discutible.
1640
1641
1642 Precisión
1643 ^^^^^^^^^
1644 Este fue históricamente uno de los problemas principales del recolector de D_
1645 [NGD46407]_ [NGD35364]_. Sin embargo, desde que, en la versión 1.001, se ha
1646 incorporado la capacidad de marcar un bloque como de datos puros (no contiene
1647 punteros, el atributo ``NO_SCAN``) [NGA6842]_, la gravedad de esos problemas ha
1648 disminuido considerablemente, aunque siguieron reportándose problemas más
1649 esporádicamente [NGD54084]_ [NGL13744]_.
1650
1651 De todas maneras queda mucho lugar para mejoras, y es un tema recurrente en el
1652 grupo de noticias de D_ y se han discutido formas de poder hacer que, al menos
1653 el *heap* sea preciso [NGD44607]_ [NGD29291]_. Además se mostró un interés
1654 general por tener un recolector más preciso [NGDN87831]_, pero no han habido
1655 avances al respecto.
1656
1657 Otra forma de minimizar los efectos de la falta de precisión que se ha
1658 sugerido reiteradamente en el grupo es teniendo la
1659 posibilidad de indicar cuando no pueden haber punteros interiores a un bloque
1660 [NGD89394]_ [NGD71869]_. Esto puede ser de gran utilidad para objetos grandes
1661 y en particular para mejorar la implementación de de arreglos asociativos.
1662
1663
1664 Referencias débiles
1665 ^^^^^^^^^^^^^^^^^^^
1666 El recolector actual no dispone de soporte de *referencias débiles*
1667 [#dgcweakref]_, sin embargo hay una demanda apreciable [NGD86840]_ [NGD13301]_
1668 [NGL8264]_ [NGD69761]_ [NGD74624]_ [NGD88065]_.
1669
1670 .. [#dgcweakref] Una referencia débil (o *weak reference* en inglés) es
1671    aquella que que no protege al objeto referenciado de ser reciclado por el
1672    recolector.
1673
1674 Para cubrir esta demanda, se han implementado soluciones como biblioteca para
1675 suplir la inexistencia de una implementación oficial [NGA9103]_.
1676
1677 Sin embargo éstas son en general poco robustas, extremadamente dependientes
1678 de la implementación del recolector y, en general, presentan problemas muy
1679 sutiles [NGD88065]_. Por esta razón se ha discutido la posibilidad de incluir
1680 la implementación de *referencias débiles* como parte del lenguaje
1681 [NGD88559]_.
1682
1683
1684 Concurrencia
1685 ^^^^^^^^^^^^
1686 El soporte actual de concurrencia, en todos sus aspectos, es muy primitivo. El
1687 recolector apenas soporta múltiples *mutators* pero con un nivel de
1688 sincronización excesivo.
1689
1690 Se ha sugerido en el pasado el uso de *pools* y listas de libres específicos
1691 de hilos, de manera de disminuir la contención, al menos para la asignación de
1692 memoria [NGD75952]_ [NGDN87831]_.
1693
1694 Además se ha mostrado un interés por tener un nivel de concurrencia aún mayor
1695 en el recolector, para aumentar la concurrencia en ambientes *multi-core* en
1696 general pero en particular para evitar grandes pausas en programas con
1697 requerimientos de tiempo real, históricamente una de las principales críticas
1698 al lenguaje [NGDN87831]_ [NGL3937]_ [NGD22968]_ [NGA15246]_ [NGD5622]_
1699 [NGD2547]_ [NGD18354]_.
1700
1701
1702 Finalización
1703 ^^^^^^^^^^^^
1704 El recolector actual no garantiza la finalización de objetos. En particular
1705 los objetos no son finalizados (es decir, no se llama a sus destructores)
1706 si aún alcanzables desde el *root set* cuando el programa termina. Cabe
1707 destacar que esto puede darse porque hay una referencia real desde el *root
1708 set* (en cuyo caso queda bajo el control del usuario) pero también, dado que
1709 el *root set* se visita de forma conservativa, se puede deber a un falso
1710 positivo, en cuyo caso la omisión de la finalización queda por completo fuera
1711 del control del usuario (y lo que es aún peor, el usuario no puede ser
1712 siquiera notificado de esta anomalía).
1713
1714 Si bien la especificación de D_ no requiere esta capacidad (de hecho,
1715 rigurosamente hablando la especificación de D_ no garantiza la finalización de
1716 objetos bajo ninguna circunstancia), no hay mayores problemas para implementar
1717 un recolector que de este tipo de garantías [NGD88298]_.
1718
1719 Además los objetos pueden ser finalizados tanto determinísticamente
1720 (utilizando ``delete`` o ``scope``; ver secciones :ref:`d_low_level`
1721 y :ref:`d_dbc`) como no determinísticamente (cuando son finalizados por el
1722 recolector). En el primer caso se puede, por ejemplo, acceder sus atributos
1723 u otra memoria que se conozca *viva*, mientras que en el segundo no. Sin
1724 embargo un destructor no puede hacer uso de esta distinción, haciendo que la
1725 finalización determinística tenga a fines prácticos las mismas restricciones
1726 que la finalización no determinística. Es por esto que se ha sugerido permitir
1727 al destructor distinguir estos dos tipos de finalización [NGD89302]_.
1728
1729
1730 Eficiencia
1731 ^^^^^^^^^^
1732 El rendimiento en general del recolector es una de las críticas frecuentes. Si
1733 bien hay muchos problemas que han sido resueltos, en especial por la inclusión
1734 de un mínimo grado de precisión en la versión 1.001, en la actualidad se
1735 siguen encontrando en el grupo de noticias críticas respecto a esto
1736 [NGD43991]_ [NGD67673]_ [NGD63541]_ [NGD90977]_.
1737
1738 La principal causa del bajo rendimiento del recolector actual es,
1739 probablemente, lo simple de su algoritmo principal de recolección. Más allá de
1740 una organización del *heap* moderadamente apropiada y de utilizar conjuntos de
1741 bits para la fase de marcado, el resto del algoritmo es casi la versión más
1742 básica de marcado y barrido. Hay mucho lugar para mejoras en este sentido.
1743
1744
1745 Configurabilidad
1746 ^^^^^^^^^^^^^^^^
1747 Si bien el recolector actual tiene algunas características configurables,
1748 todas son seleccionables sólo en tiempo de compilación del recolector (no del
1749 programa del usuario), como por ejemplo las opciones descriptas en
1750 :ref:`dgc_debug`. Por lo tanto, a nivel práctico, es como si no tuviera
1751 posibilidad alguna de ser configurado por el usuario, ya que no es parte del
1752 ciclo de desarrollo normal el recompilar el recolector o *runtime* de un
1753 lenguaje.
1754
1755 Dado que es imposible que un recolector sea óptimo para todo tipo de
1756 programas, es muy deseable permitir una configuración de parámetros del
1757 recolector que permitan al usuario ajustarlo a las necesidades particulares de
1758 sus programas.
1759
1760
1761 .. _dgc_bad_ocup:
1762
1763 Factor de ocupación del *heap*
1764 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1765 Otro problema potencialmente importante del recolector actual es que no se
1766 tiene ningún cuidado con respecto a que, luego de una recolección, se haya
1767 recuperado una buena parte del *heap*. Por lo tanto, en casos extremos, el
1768 recolector tiene que hacer una recolección por cada petición de memoria, lo
1769 que es extremadamente ineficiente.
1770
1771 Para evitar esto, habría que usar algún esquema para evaluar cuando una
1772 recolección no fue lo suficientemente *exitosa* y en ese caso pedir más
1773 memoria al sistema operativo.
1774
1775
1776 Detalles
1777 ^^^^^^^^
1778 Finalmente hay varios detalles en la implementación actual que podrían
1779 mejorarse:
1780
1781 Listas de libres
1782    hay 12 listas de libres, como para guardar bloques de tamaño de ``B_16``
1783    a ``B_2048``, ``B_PAGE``, ``B_PAGEPLUS``, ``B_UNCOMMITTED`` y ``B_FREE``;
1784    sin embargo solo tienen sentido los bloques de tamaño ``B_16``
1785    a ``B_2048``, por lo que 4 de esas listas no se utilizan.
1786
1787 Conjuntos de bits para indicadores
1788    los indicadores para la fase de marcado y otras propiedades de un bloque
1789    son almacenados en conjuntos de bits que almacenan los indicadores de todos
1790    los bloques de un *pool*. Si bien se ha mencionado esto como una ventaja,
1791    hay lugar todavía como para algunas mejoras. Como un *pool* tiene páginas
1792    con distintos tamaños de bloque, se reserva una cantidad de bits igual a la
1793    mayor cantidad posible de bloques que puede haber en el *pool*; es decir,
1794    se reserva 1 bit por cada 16 bytes del *pool*. Para un *pool* de 1 MiB
1795    (tamaño mínimo), teniendo en cuenta que se utilizan 5 conjuntos de bits
1796    (``mark``, ``scan``, ``finals``, ``freebits`` y ``noscan``), se utilizan 40
1797    KiB de memoria para conjuntos de bits (un 4% de *desperdicio* si, por
1798    ejemplo, ese *pool* estuviera destinado por completo a albergar un solo
1799    objeto grande; lo que equivaldría al 2560 objetos de 16 bytes
1800    desperdiciados en bits inutilizados).
1801
1802 Repetición de código
1803    Hay algunos fragmentos de código repetidos innecesariamente. Por ejemplo en
1804    varios lugares se utilizan arreglos de tamaño variable que se implementan
1805    repetidas veces (en general como un puntero al inicio del arreglo más el
1806    tamaño actual del arreglo más el tamaño de la memoria total asignada
1807    actualmente). Esto es propenso a errores y difícil de mantener.
1808
1809 Uso de señales
1810    el recolector actual utiliza las señales del sistema operativo ``SIGUSR1``
1811    y ``SIGUSR2`` para pausar y reanudar los hilos respectivamente. Esto
1812    puede traer inconvenientes a usuarios que desean utilizar estas
1813    señales en sus programas (o peor aún, si interactúan con bibliotecas
1814    de C que hacen uso de estas señales) [NGD5821]_.
1815
1816 Marcado iterativo
1817    si bien esto se mencionó como algo bueno del recolector actual, es un
1818    compromiso entre tiempo y espacio, y puede ser interesante analizar otros
1819    métodos para evitar la recursión que no requieran tantas pasadas sobre el
1820    *heap*.
1821
1822
1823 .. include:: links.rst
1824
1825 .. vim: set ts=3 sts=3 sw=3 et tw=78 spelllang=es :