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       mark_stacks()
 465       mark_user_roots()
 466       mark_heap()
 467       start_the_world()
 468
 469 La variable **global** ``more_to_scan`` indica al algoritmo iterativo cuando
 470 debe finalizar: la función ``mark_range()`` (que veremos más adelante) lo pone
 471 en ``true`` cuando una nueva celda debe ser visitada, por lo tanto la
 472 iteración se interrumpe cuando no hay más celdas por visitar.
 473
 474 Las funciones ``stop_the_world()`` y ``start_the_world()`` sencillamente
 475 pausan y reanudan todos los hilos respectivamente::
 476
 477    function stop_the_world() is
 478       foreach thread in threads
 479          thread.pause()
 480
 481    function start_the_world() is
 482       foreach thread in threads
 483          thread.resume()
 484
 485 La función ``clear_mark_scan_bits()`` se encarga de restablecer todos los
 486 atributos *mark* y *scan* de cada bloque del *heap*::
 487
 488    function clear_mark_scan_bits() is
 489       foreach pool in heap
 490          foreach page in pool
 491             foreach block in page
 492                block.mark = false
 493                block.scan = false
 494
 495 La función ``mark_free_lists()`` por su parte se encarga de activar el bit
 496 *mark* de todos los bloques de las listas de libres de manera de que la fase
 497 de marcado (que es iterativa y realiza varias pasadas sobre **todo** el
 498 *heap*, incluyendo las celdas libres) no visite las celdas libres perdiendo
 499 tiempo sin sentido y potencialmente manteniendo *vivas* celdas que en
 500 realidad son *basura* (falsos positivos)::
 501
 502    function mark_free_lists() is
 503       foreach free_list in heap
 504          foreach block in free_list
 505             block.mark = true
 506             block.free = true
 507
 508 Notar que los bloques libres quedan entonces marcados aunque sean *basura* por
 509 definición. Para evitar que en la etapa de barrido se tomen estos bloques como
 510 celdas vivas, a todos los bloques en la lista de libres también se los marca
 511 con el bit *free*, así el barrido puede tomar como *basura* estos bloques
 512 aunque estén marcados.
 513
 514 El *root set* está compuesto por el área de memoria estática (variables
 515 globales), los *stacks* de todos los hilos y los registros del procesador.
 516 Primero se marca el área de memoria estática de manera :ref:`conservativa
 517 <gc_conserv>` (es decir, tomando cada *word* como si fuera un puntero)::
 518
 519    function mark_static_data() is
 520       mark_range(static_data.begin, static_data.end)
 521
 522 Para poder tomar los registros como parte del *root set* primero se apilan
 523 en el *stack* a través de la función::
 524
 525    function push_registers_into_stack() is
 526       foreach register in registers
 527          push(register)
 528
 529 Una vez hecho esto, basta marcar (de forma conservativa) los *stacks* de todos
 530 los threads para terminar de marcar el *root set*::
 531
 532    function mark_stacks() is
 533       foreach thread in threads
 534          mark_range(thread.stack.begin, thread.stack.end)
 535
 536 Dado que D_ soporta manejo de memoria manual al mismo tiempo que memoria
 537 automática, es posible que existan celdas de memoria que no estén en el *root
 538 set* convencional ni en el *heap* del recolector. Para evitar que se libere
 539 alguna celda a la cual todavía existen referencias desde memoria administrada
 540 por el usuario, éste debe informarle al recolector sobre la existencia de
 541 estas nuevas raíces. Es por esto que para concluir el marcado del *root set*
 542 completo se procede a marcar las raíces definidas por el usuario::
 543
 544    function mark_user_roots() is
 545       foreach root_range in user_roots
 546          mark_range(root_range.begin, root_range.end)
 547
 548 El algoritmo de marcado no es recursivo sino iterativo por lo tanto al marcar
 549 una celda (o bloque) no se siguen sus *hijas*, solo se activa el bit de *scan*
 550 (a menos que la celda no contenga punteros, es decir, tenga el bit *noscan*)::
 551
 552    function mark_range(begin, end) is
 553       pointer = begin
 554       while pointer < end
 555          [pool, page, block] = find_block(pointer)
 556          if block is not null and block.mark is false
 557             block.mark = true
 558             if block.noscan is false
 559                block.scan = true
 560                global more_to_scan = true
 561          pointer++
 562
 563 Por lo tanto en este punto, tenemos todas las celdas inmediatamente
 564 alcanzables desde el *root set* marcadas y con el bit *scan* activado si la
 565 celda puede contener punteros. Por lo tanto solo resta marcar (nuevamente de
 566 forma conservativa) iterativamente todo el *heap* hasta que no hayan más
 567 celdas para visitar (con el bit *scan* activo)::
 568
 569    function mark_heap() is
 570       while global more_to_scan
 571          global more_to_scan = false
 572          foreach pool in heap
 573             foreach page in pool
 574                if page.block_size <= PAGE // saltea FREE y CONTINUATION
 575                   foreach block in page
 576                      if block.scan is true
 577                         block.scan = false
 578                         if page.block_size is PAGE // objeto grande
 579                            begin = cast(byte*) page
 580                            end = find_big_object_end(pool, page)
 581                            mark_range(begin, end)
 582                         else // objeto pequeño
 583                            mark_range(block.begin, block.end)
 584
 585 Aquí puede verse, con un poco de esfuerzo, la utilización de la
 586 :ref:`abstracción tricolor <gc_intro_tricolor>`: todas las celdas alcanzables
 587 desde el *root set* son pintadas de *gris* (tienen los bits *mark* y *scan*
 588 activados), excepto aquellas celdas atómicas (es decir, que se sabe que no
 589 tienen punteros) que son marcadas directamente de *negro*. Luego se van
 590 obteniendo celdas del conjunto de las *grises*, se las pinta de *negro* (es
 591 decir, se desactiva el bit *scan*) y se pintan todas sus *hijas* de *gris* (o
 592 *negro* directamente si no tienen punteros). Este procedimiento se repite
 593 mientras el conjunto de celdas *grises* no sea vacío (es decir, que
 594 ``more_to_scan`` sea ``true``).
 595
 596 A continuación se presenta la implementación de las funciones suplementarias
 597 utilizadas en la fase de marcado::
 598
 599    function find_big_object_end(pool, page) is
 600       pool_end = cast(byte*) pool.pages + (PAGE_SIZE * pool.number_of_pages)
 601       do
 602          page = cast(byte*) page + PAGE_SIZE
 603       while page.block_size is CONTINUATION and page < pool_end
 604       return page
 605
 606    function find_block(pointer) is
 607       foreach pool in heap
 608          foreach page in pool
 609             if page.block_size is PAGE
 610                big_object_start = cast(byte*) page
 611                big_object_end = find_big_object_end(pool, page)
 612                if big_object_start <= pointer < big_object_end
 613                   return [pool, page, big_object_start]
 614             else if page.bloc_size < PAGE
 615                foreach block in page
 616                   block_start = cast(byte*) block
 617                   block_end = block_start + page.block_size
 618                   if block_start <= pointer < block_end
 619                      return [pool, page, block_start]
 620       return [null, null, null]
 621
 622 Cabe destacar que la función ``find_block()`` devuelve el *pool*, la página
 623 y el comienzo del bloque al que apunta el puntero, es decir, soporta punteros
 624 *interiores*.
 625
 626
 627 .. _dgc_algo_sweep:
 628
 629 Fase de barrido
 630 ^^^^^^^^^^^^^^^
 631 Esta fase es considerablemente más sencilla que el marcado; el algoritmo puede
 632 dividirse en dos pasos básicos::
 633
 634    function sweep_phase() is
 635       sweep()
 636       rebuild_free_lists()
 637
 638 El barrido se realiza con una pasada por sobre todo el *heap* de la siguiente
 639 manera::
 640
 641    function sweep() is
 642       foreach pool in heap
 643          foreach page in pool
 644             if page.block_size <= PAGE // saltea FREE y CONTINUATION
 645                foreach block in page
 646                   if block.mark is false
 647                      if block.final is true
 648                         finalize(block)
 649                      block.free = true
 650                      block.final = false
 651                      block.noscan = false
 652                      if page.block_size is PAGE // objeto grande
 653                         free_big_object(pool, page)
 654
 655 Como se observa, se recorre todo el *heap* en busca de bloques y páginas
 656 libres. Los bloques libres son marcados con el atributo ``free`` y las páginas
 657 libres son marcadas con el tamaño de bloque simbólico ``FREE``. Para los
 658 objetos grandes se marcan todas las páginas que utilizaban como ``FREE``::
 659
 660    function free_big_object(pool, page) is
 661       pool_end = cast(byte*) pool.pages + (PAGE_SIZE * pool.number_of_pages)
 662       do
 663          page = cast(byte*) page + PAGE_SIZE
 664          page.block_size = FREE
 665       while page.block_size is CONTINUATION and page < pool_end
 666
 667 Además, los bloques que tienen en atributo ``final`` son finalizados llamando
 668 a la función ``finalize()``. Esta función es un servicio que provee la
 669 biblioteca *runtime* y en última instancia llama al destructor del objeto
 670 almacenado en el bloque a liberar.
 671
 672 Una vez marcados todos los bloques y páginas como libre, se procede
 673 a reconstruir las listas de libres. En el proceso buscan las páginas que
 674 tengan todos los bloques libres para marcar la página completa como libre (de
 675 manera que pueda utilizarse para albergar otro tamaño de bloque u objetos
 676 grandes de ser necesario)::
 677
 678    function rebuild_free_lists() is
 679       foreach free_list in heap
 680          free_list.clear()
 681       foreach pool in heap
 682          foreach page in pool
 683             if page.block_size < PAGE // objetos pequeños
 684                if is_page_free(page)
 685                   page.block_size = FREE
 686                else
 687                   foreach block in page
 688                      if block.free is true
 689                         free_lists[page.block_size].link(block)
 690
 691 Esta reorganización de listas libres además mejoran la localidad de
 692 referencia y previenen la fragmentación. La localidad de referencia se ve
 693 mejorada debido a que asignaciones de memoria próximas en el tiempo serán
 694 también próximas en espacio porque pertenecerán a la misma página (al menos si
 695 las asignaciones son todas del mismo tamaño). La fragmentación se minimiza por
 696 el mismo efecto, primero se asignarán todos los bloques de la misma página.
 697
 698 A continuación se presenta la implementación de una de las funciones
 699 suplementarias de la fase de barrido::
 700
 701    function is_page_free(page) is
 702       foreach block in page
 703          if block.free is false
 704             return false
 705       return true
 706
 707 Las demás funciones suplementarias pertenecen a la manipulación de listas
 708 libres que no son más que operaciones sobre una lista simplemente enlazada. En
 709 la sección :ref:`dgc_impl` se verá con más detalles como las implementa el
 710 recolector actual.
 711
 712
 713 .. _dgc_algo_alloc:
 714
 715 Asignación de memoria
 716 ^^^^^^^^^^^^^^^^^^^^^
 717 La asignación de memoria del recolector es relativamente compleja, excepto
 718 cuando se asigna un objeto pequeño y ya existe algún bloque con el tamaño
 719 preciso en la lista de libres. Para el resto de los casos la cantidad de
 720 trabajo que debe hacer el recolector para asignar la memoria es considerable.
 721
 722 El algoritmo de asignación de memoria se puede resumir así::
 723
 724    function new(size, attrs) is
 725       block_size = find_block_size(size)
 726       if block_size < PAGE
 727          block = new_small(block_size)
 728       else
 729          block = new_big(size)
 730       if block is null
 731          throw out_of_memory
 732       if final in attrs
 733          block.final = true
 734       if noscan in attrs
 735          block.noscan = true
 736       return cast(void*) block
 737
 738 La función ``find_block_size()`` sencillamente busca el tamaño de bloque se
 739 mejor se ajuste al tamaño solicitado (es decir, el bloque más pequeño lo
 740 suficientemente grande como para poder almacenar el tamaño solicitado). Una
 741 vez más el algoritmo distingue objetos grandes de pequeños. Los pequeños se
 742 asignan de las siguiente manera::
 743
 744       function new_small(block_size) is
 745          block = find_block_with_size(block_size)
 746          if block is null
 747             collect()
 748             block = find_block_with_size(block_size)
 749             if block is null
 750                new_pool()
 751                block = find_block_with_size(block_size)
 752                return null
 753          return block
 754
 755 Se intenta reiteradas veces conseguir un bloque del tamaño correcto libre,
 756 realizando diferentes acciones si no se tiene éxito. Primero se intenta hacer
 757 una :ref:`recolección <dgc_algo_collect>` y si no se puede encontrar
 758 suficiente espacio luego de ella se intenta crear un nuevo *pool* de memoria
 759 pidiendo memoria al *low level allocator* (el sistema operativo generalmente).
 760
 761 Para intentar buscar un bloque de memoria libre se realiza lo siguiente::
 762
 763       function find_block_with_size(block_size) is
 764          block = free_lists[block_size].pop_first()
 765          if block is null
 766             assign_page(block_size)
 767             block = free_lists[block_size].pop_first()
 768          return block
 769
 770 Si no se puede obtener un bloque de la lista de libres correspondiente, se
 771 busca asignar una página libre al tamaño de bloque deseado de forma de
 772 *alimentar* la lista de libres con dicho tamaño::
 773
 774       function assign_page(block_size) is
 775          foreach pool in heap
 776             foreach page in pool
 777                if page.block_size is FREE
 778                   page.block_size = block_size
 779                   foreach block in page
 780                      free_lists[page.block_size].link(block)
 781
 782 Cuando todo ello falla, el último recurso consiste en pedir memoria al sistema
 783 operativo, creando un nuevo *pool*::
 784
 785       funciones new_pool(number_of_pages = 1) is
 786          pool = alloc(pool.sizeof)
 787          if pool is null
 788             return null
 789          pool.number_of_pages = number_of_pages
 790          pool.pages = alloc(number_of_pages * PAGE_SIZE)
 791          if pool.pages is null
 792             free(pool)
 793             return null
 794          heap.add(pool)
 795          return pool
 796
 797 Se recuerda que la función ``alloc()`` es un :ref:`servicio
 798 <gc_intro_services>` provisto por el *low level allocator* y en la
 799 implementación actual de D_ en general es el sistema operativo (aunque
 800 opcionalmente puede utilizarse la biblioteca estándar de C, que a su vez
 801 utiliza el sistema operativo).
 802
 803 Cualquier error en estas funciones es propagado y en última instancia, cuando
 804 todo falla, la función ``new()`` termina lanzando una excepción indicando que
 805 se agotó la memoria.
 806
 807 Si el tamaño de bloque necesario para cumplir con la asignación de memoria es
 808 de una página, entonces se utiliza otro algoritmo para alocar un objeto
 809 grande::
 810
 811       function new_big(size) is
 812          number_of_pages = ceil(size / PAGE_SIZE)
 813          pages = find_pages(number_of_pages)
 814          if pages is null
 815             collect()
 816             pages = find_pages(number_of_pages)
 817             if pages is null
 818                minimize()
 819                pool = new_pool(number_of_pages)
 820                if pool is null
 821                   return null
 822                pages = assign_pages(pool, number_of_pages)
 823          pages[0].block_size = PAGE
 824          foreach page in pages[1..end]
 825             page.block_size = CONTINUATION
 826          return pages[0]
 827
 828 De forma similar a la asignación de objetos pequeños, se intenta encontrar una
 829 serie de páginas contiguas, dentro de un mismo *pool*, suficientes para
 830 almacenar el tamaño requerido y si esto falla, se realizan diferentes pasos
 831 y se vuelve a intentar. Puede observarse que, a diferencia de la asignación de
 832 objetos pequeños, si luego de la recolección no se pudo encontrar lugar
 833 suficiente, se trata de minimizar el uso de memoria física utilizando la
 834 siguiente función, que devuelve al *low level allocator* los *pools*
 835 completamente libres::
 836
 837    function minimize() is
 838       for pool in heap
 839          all_free = true
 840          for page in pool
 841             if page.block_size is not FREE
 842                all_free = false
 843                break
 844          if all_free is true
 845             free(pool.pages)
 846             free(pool)
 847             heap.remove(pool)
 848
 849 Volviendo a la función ``new_big()``, para hallar una serie de páginas
 850 contiguas se utiliza el siguiente algoritmo::
 851
 852       function find_pages(number_of_pages) is
 853          foreach pool in heap
 854             pages = assign_pages(pool, number_of_pages)
 855             if pages
 856                return pages
 857          return null
 858
 859 Como se dijo, las páginas deben estar contenidas en un mismo *pool* (para
 860 tener la garantía de que sean contiguas), por lo tanto se busca *pool* por
 861 *pool* dicha cantidad de páginas libres consecutivas a través del siguiente
 862 algoritmo::
 863
 864       function assign_pages(pool, number_of_pages) is
 865          pages_found = 0
 866          first_page = null
 867          foreach page in pool
 868             if page.block_size is FREE
 869                if pages_found is 0
 870                   pages_found = 1
 871                   first_page = page
 872                else
 873                   pages_found = pages_found + 1
 874                if pages_found is number_of_pages
 875                   return [first_page .. page]
 876             else
 877                pages_found = 0
 878                first_page = null
 879          return null
 880
 881 Una vez más, cuando todo ello falla (incluso luego de una recolección), se
 882 intenta alocar un nuevo *pool*, esta vez con una cantidad de páginas
 883 suficientes como para almacenar el objeto grande y si esto falla el error se
 884 propaga hasta la función ``new()`` que lanza una excepción.
 885
 886
 887 .. _dgc_algo_free:
 888
 889 Liberación de memoria
 890 ^^^^^^^^^^^^^^^^^^^^^
 891 La liberación de la memoria asignada puede hacerse explícitamente. Esto
 892 saltea el mecanismo de recolección, y es utilizado para dar soporte a manejo
 893 explícito de memoria asignada en el *heap* del recolector. En general el
 894 usuario no debe utilizar liberación explícita, pero puede ser útil en casos
 895 muy particulares::
 896
 897    function delete(pointer) is
 898       [pool, page, block_start] = find_block(pointer)
 899       if block is not null
 900          block.free = true
 901          block.final = false
 902          block.noscan = false
 903          if page.block_size is PAGE // objeto grande
 904             free_big_object(pool, page)
 905          else // objeto pequeño
 906             free_lists[page.block_size].link(block)
 907
 908 Como se puede observar, si el objeto es pequeño se enlaza a la lista de libres
 909 correspondiente y si es grande se liberan todas las páginas asociadas a éste,
 910 de forma similar a la :ref:`fase de barrido <dgc_algo_sweep>`. A diferencia de
 911 ésta, no se finaliza el objeto (es decir, no se llama a su destructor).
 912
 913
 914 .. _dgc_algo_final:
 915
 916 Finalización
 917 ^^^^^^^^^^^^
 918 Al finalizar el programa, el recolector es finalizado también y lo que realiza
 919 actualmente, además de liberar la memoria propia del recolector, es realizar
 920 una recolección. Es decir, si hay objetos que son todavía alcanzables desde el
 921 *root set*, esos objetos no son finalizados (y por lo tanto sus destructores
 922 no son ejecutados).
 923
 924 Como se ha visto, esto es perfectamente válido ya que D_ no garantiza que los
 925 objetos sean finalizados.
 926
 927
 928
 929 .. _dgc_impl:
 930
 931 Detalles de implementación
 932 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 933
 934 Hay varias diferencias a nivel de implementación entre lo que se presentó en
 935 las secciones anteriores y como está implementado realmente el recolector
 936 actual. Con los conceptos e ideas principales del ya explicadas, se procede
 937 a ahondar con más detalle en como está construido el recolector y algunas de
 938 sus optimizaciones principales.
 939
 940 Vale aclarar que el recolector de basura actual está implementado en D_.
 941
 942
 943 Estructuras de datos del recolector
 944 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 945 El recolector está principalmente contenido en la estructura llamada ``Gcx``.
 946 Dicha estructura tiene los siguientes atributos (divididos en categorías para
 947 facilitar la comprensión):
 948
 949 Raíces definidas por el usuario
 950    *roots* (*nroots*, *rootdim*)
 951       arreglo variable de punteros simples que son tomados como raíces
 952       provistas por el usuario.
 953
 954    *ranges* (*nranges*, *rangedim*)
 955       arreglo variable de rangos de memoria que deben ser revisados (de forma
 956       conservativa) como raíces provistas por el usuario. Un rango es una
 957       estructura con dos punteros: ``pbot`` y ``ptop``. Toda la memoria entre
 958       estos dos punteros se toma, palabra por palabra, como una raíz del
 959       recolector.
 960
 961 Estado interno del recolector
 962    *anychanges*
 963       variable que indica si en la fase de marcado se encontraron nuevas
 964       celdas con punteros que deban ser visitados. Otra forma de verlo es como
 965       un indicador de si el conjunto de celdas *grises* está vacío luego de
 966       una iteración de marcado (utilizando la :ref:`abstracción tricolor
 967       <gc_intro_tricolor>`). Es análoga a la variable ``more_to_scan``
 968       presentada en :ref:`dgc_algo_mark`.
 969
 970    *inited*
 971       indica si el recolector fue inicializado.
 972
 973    *stackBottom*
 974       puntero a la base del *stack* (asumiendo que el stack crece hacia arriba).
 975       Se utiliza para saber por donde comenzar a visitar el *stack* de forma
 976       conservativa, tomándolo con una raíz del recolector.
 977
 978    *Pools* (*pooltable*, *npools*)
 979       arreglo variable de punteros a estructuras ``Pool`` (ver más adelante).
 980       Este arreglo se mantiene siempre ordenado de menor a mayor según la
 981       dirección de memoria de la primera página que almacena.
 982
 983    *bucket*
 984       listas de libres. Es un arreglo de estructuras ``List`` utilizadas para
 985       guardar la listas de libres de todos los tamaños de bloques posibles (ver
 986       más adelante).
 987
 988 Atributos que cambian el comportamiento
 989    *noStack*
 990       indica que no debe tomarse al *stack* como raíz del recolector. Esto es
 991       muy poco seguro y no debería ser utilizado nunca, salvo casos
 992       extremadamente excepcionales.
 993
 994    *log*
 995       indica si se debe guardar un registro de la actividad del recolector. Es
 996       utilizado principalmente para depuración.
 997
 998    *disabled*
 999       indica que no se deben realizar recolecciones implícitamente. Si al
1000       tratar de asignar memoria no se puede hallar celdas libres en el *heap*
1001       del recolector, se pide más memoria al sistema operativo sin correr una
1002       recolección para intentar recuperar espacio. Esto es particularmente
1003       útil para secciones de un programa donde el rendimiento es crítico y no
1004       se pueden tolerar grandes pausas como las que puede provocar el
1005       recolector.
1006
1007 Optimizaciones
1008    *p_cache*, *size_cache*
1009       obtener el tamaño de un bloque dado un puntero es una tarea costosa
1010       y común. Para evitarla en casos donde se calcula de forma sucesiva el
1011       tamaño del mismo bloque (como puede ocurrir al concatenar arreglos
1012       dinámicos) se guarda el último calculado en estas variables a modo de
1013       *caché*.
1014
1015    *minAddr*, *maxAddr*
1016       punteros al principio y fin del *heap*. Pueden haber *huecos* entre
1017       estos dos punteros que no pertenezcan al *heap* pero siempre se cumple
1018       que si un puntero apunta al *heap* debe estar en este rango. Esto es
1019       útil para hacer un cálculo rápido para descartar punteros que fueron
1020       tomados de forma conservativa y en realidad no apuntan al *heap* (ver la
1021       función ``find_block()`` en :ref:`dgc_algo_mark`).
1022
1023
1024 *Pools*
1025 ^^^^^^^
1026 La primera diferencia es como está organizado el *heap*. Si bien la
1027 explicación presentada en la sección :ref:`dgc_org` es correcta, la forma en
1028 la que está implementado no es tan *naïve* como los algoritmos presentados en
1029 :ref:`dgc_algo` sugieren.
1030
1031 El recolector guarda un arreglo variable de estructuras ``Pool``. Cabe
1032 destacar que para implementar el recolector no se pueden utilizar los arreglos
1033 dinámicos de D_ (ver sección :ref:`d_high_level`) dado que éstos utilizan de
1034 forma implícita el recolector de basura, por lo tanto todos los arreglos
1035 variables del recolector se implementan utilizando las funciones de
1036 C ``malloc()``, ``realloc()`` y ``free()`` directamente.
1037
1038
1039 La estructura ``Pool`` está compuesta por los siguientes atributos (ver figura
1040 :vref:`fig:dgc-pool`):
1041
1042 *baseAddr* y *topAddr*
1043    punteros al comienzo y fin de la memoria que almacena todas las páginas del
1044    *pool* (*baseAddr* es análogo al atributo *pages* utilizado en las
1045    secciones anteriores para mayor claridad).
1046
1047 *mark*, *scan*, *freebits*, *finals*, *noscan*
1048    conjunto de bits (*bitsets*) para almacenar los indicadores descriptos en
1049    :ref:`dgc_org` para todos los bloques de todas las páginas del *pool*.
1050    *freebits* es análogo a *free* y *finals* a *final* en los atributos
1051    descriptos en las secciones anteriores.
1052
1053 *npages*
1054    cantidad de páginas que contiene este *pool* (fue nombrado
1055    *number_of_pages* en las secciones anteriores para mayor claridad).
1056
1057 *ncommitted*
1058    cantidad de páginas *encomendadas* al sistema operativo (*committed* en
1059    inglés). Este atributo no se mencionó anteriormente porque el manejo de
1060    páginas encomendadas le agrega una complejidad bastante notable al
1061    recolector y es solo una optimización para un sistema operativo en
1062    particular (Microsoft Windows).
1063
1064 *pagetable*
1065    arreglo de indicadores de tamaño de bloque de cada página de este *pool*.
1066    Los indicadores válidos son ``B_16`` a ``B_2048`` (pasando por los valores
1067    posibles de bloque mencionados anteriormente, todos con el prefijo
1068    "``B_``"), ``B_PAGE``, ``B_PAGEPLUS`` (análogo a ``CONTINUATION``),
1069    ``B_UNCOMMITTED`` (valor que tienen las páginas que no fueron encomendadas
1070    aún) y ``B_FREE``.
1071
1072 .. fig:: fig:dgc-pool
1073
1074    Vista gráfica de la estructura de un *pool* de memoria.
1075
1076    .. aafig::
1077       :scale: 120
1078
1079                 /---  "baseAddr"    "ncommitted = i"          "topAddr" ---\
1080                 |                       V                                  |
1081                 |/                      |/                                 |/
1082                 +----  "committed" -----+-------  "no committed" ----------+
1083                /|                      /|                                 /|
1084                 V                       V                                  V
1085                 +--------+--------+-----+--------+-----+-------------------+
1086         páginas |   0    |   0    | ... |   i    | ... |    "npages - 1"   |
1087                 +--------+--------+-----+--------+-----+-------------------+
1088                     A        A      A       A      A           A
1089                     |        |      |       |      |           |
1090                 +--------+--------+-----+--------+-----+-------------------+
1091       pagetable | Bins 0 | Bins 1 | ... | Bins i | ... | "Bins (npages-1)" |
1092                 +--------+--------+-----+--------+-----+-------------------+
1093
1094 Como se observa, además de la información particular del *pool* se almacena
1095 toda la información de páginas y bloques enteramente en el *pool* también.
1096 Esto simplifica el manejo de que lo es memoria *pura* del *heap*, ya que queda
1097 una gran porción continua de memoria sin estar intercalada con
1098 meta-información del recolector.
1099
1100 Para poder acceder a los bits de un bloque en particular, se utiliza la
1101 siguiente cuenta para calcular el índice en el *bitset*:
1102
1103 .. math::
1104
1105    index(p) = \frac{p - baseAddr}{16}
1106
1107 Donde ``p`` es la dirección de memoria del bloque. Esto significa que, sin
1108 importar cual es el tamaño de bloque de las páginas del *pool*, el *pool*
1109 siempre reserva suficientes bits como para que todas las páginas puedan tener
1110 tamaño de bloque de 16 bytes. Esto puede ser desperdiciar bastante espacio si
1111 no predomina un tamaño de bloque pequeño.
1112
1113
1114 Listas de libres
1115 ^^^^^^^^^^^^^^^^
1116 Las listas de libres se almacenan en el recolector como un arreglo de
1117 estructuras ``Lista``, que se compone solamente de un atributo ``List* next``
1118 (es decir, un puntero al siguiente). Entonces cada elemento de ese arreglo es
1119 un puntero al primer elemento de la lista en particular.
1120
1121 La implementación utiliza a los bloques de memoria como nodos directamente.
1122 Como los bloques siempre pueden almacenar una palabra (el bloque de menor
1123 tamaño es de 16 bytes y una palabra ocupa comúnmente entre 4 y 8 bytes según
1124 se trabaje sobre arquitecturas de 32 o 64 bits respectivamente), se almacena
1125 el puntero al siguiente en la primera palabra del bloque.
1126
1127
1128 Algoritmos
1129 ^^^^^^^^^^
1130 Los algoritmos en la implementación real son considerablemente menos modulares
1131 que los presentados en la sección :ref:`dgc_algo`. Por ejemplo, la función
1132 ``collect()`` es una gran función de 300 líneas de código.
1133
1134 A continuación se resumen las funciones principales, separadas en categorías
1135 para facilitar la comprensión. Los siguientes son métodos de la estructura
1136 ``Gcx``:
1137
1138 Inicialización y terminación
1139    *initialize()*
1140       inicializa las estructuras internas del recolector para que pueda ser
1141       utilizado. Esta función la llama la biblioteca *runtime* antes de que el
1142       programa comience a correr.
1143
1144    *Dtor()*
1145        libera todas las estructuras que utiliza el recolector.
1146
1147 Manipulación de raíces definidas por el usuario
1148    *addRoot(p)*, *removeRoot(p)*, *rootIter(dg)*
1149       agrega, remueve e itera sobre las raíces simples definidas por el
1150       usuario.
1151
1152    *addRange(pbot, ptop)*, *remove range(pbot)*, *rangeIter(dg)*
1153       agrega, remueve e itera sobre los rangos de raíces definidas por el
1154       usuario.
1155
1156 Manipulación de indicadores
1157    *getBits(pool, biti)*
1158       obtiene los indicadores especificados para el bloque de índice ``biti``
1159       en el *pool* ``pool``.
1160
1161    *setBits(pool, biti, mask)*
1162       establece los indicadores especificados en ``mask`` para el bloque de
1163       índice ``biti`` en el *pool* ``pool``.
1164
1165    *clrBits(pool, biti, mask)*
1166       limpia los indicadores especificados en ``mask`` para el bloque de
1167       índice ``biti`` en el *pool* ``pool``.
1168
1169    Cada bloque (*bin* en la terminología de la implementación del recolector)
1170    tiene ciertos indicadores asociados. Algunos de ellos pueden ser
1171    manipulados (indirectamente) por el usuario utilizando las funciones
1172    mencionadas arriba.
1173
1174    El parámetro ``mask`` debe ser una máscara de bits que puede estar
1175    compuesta por la conjunción de los siguientes valores:
1176
1177    *FINALIZE*
1178       el objeto almacenado en el bloque tiene un destructor (indicador
1179       *finals*).
1180
1181    *NO_SCAN*
1182       el objeto almacenado en el bloque no contiene punteros (indicador
1183       *noscan*).
1184
1185    *NO_MOVE*
1186       el objeto almacenado en el bloque no debe ser movido [#dgcmove]_.
1187
1188 .. [#dgcmove] Si bien el recolector actual no tiene la capacidad de mover
1189    objetos, la interfaz del recolector hacer que sea posible una
1190    implementación que lo haga, ya que a través de este indicador se pueden
1191    fijar objetos apuntados desde algún segmento no conservativo (objeto
1192    *pinned*).
1193
1194 Búsquedas
1195    *findPool(p)*
1196       busca el *pool* al que pertenece el objeto apuntado por ``p``.
1197
1198    *findBase(p)*
1199       busca la dirección base (el inicio) del bloque apuntado por ``p``
1200       (``find_block()`` según la sección :ref:`dgc_algo_mark`).
1201
1202    *findSize(p)*
1203       busca el tamaño del bloque apuntado por ``p``.
1204
1205    *getInfo(p)*
1206       obtiene información sobre el bloque apuntado por ``p``. Dicha
1207       información se retorna en una estructura ``BlkInfo`` que contiene los
1208       siguientes atributos: ``base`` (dirección del inicio del bloque),
1209       ``size`` (tamaño del bloque) y ``attr`` (atributos o indicadores del
1210       bloque, los que se pueden obtener con ``getBits()``).
1211
1212    *findBin(size)*
1213       calcula el tamaño de bloque más pequeño que pueda contener un objeto de
1214       tamaño ``size`` (``find_block_size()`` según lo visto en
1215       :ref:`dgc_algo_alloc`).
1216
1217 Asignación de memoria
1218    *reserve(size)*
1219       reserva un nuevo *pool* de al menos ``size`` bytes. El algoritmo nunca
1220       crea un *pool* con menos de 256 páginas (es decir, 1 MiB).
1221
1222    *minimize()*
1223       minimiza el uso de la memoria retornando *pools* sin páginas usadas al
1224       sistema operativo.
1225
1226    *newPool(n)*
1227       reserva un nuevo *pool* con al menos ``n`` páginas. Junto con
1228       ``Pool.initialize()`` es análoga a ``new_pool()``, solo que esta función
1229       siempre incrementa el número de páginas a, al menos, 256 páginas (es
1230       decir, los *pools* son siempre mayores a 1 MiB). Si la cantidad de
1231       páginas pedidas supera 256, se incrementa el número de páginas en un 50%
1232       como para que sirva para futuras asignaciones también. Además a medida
1233       que la cantidad de *pools* crece, también trata de obtener cada vez más
1234       memoria. Si ya había un *pool*, el 2do tendrá como mínimo 2 MiB, el 3ro
1235       3 MiB y así sucesivamente hasta 8 MiB. A partir de ahí siempre crea
1236       *pools* de 8 MiB o la cantidad pedida, si ésta es mayor.
1237
1238    *Pool.initialize(n_pages)*
1239       inicializa un nuevo *pool* de memoria. Junto con ``newPool()`` es
1240       análoga a ``new_pool()``. Mientras ``newPool()`` es la encargada de
1241       calcular la cantidad de páginas y crear el objeto *pool*, esta función
1242       es la que pide la memoria al sistema operativo. Además inicializa los
1243       conjuntos de bits: ``mark``, ``scan``, ``freebits``, ``noscan``.
1244       ``finals`` se inicializa de forma perezosa, cuando se intenta asignar el
1245       atributo ``FINALIZE`` a un bloque, se inicializa el conjunto de bits
1246       ``finals`` de todo el *pool*.
1247
1248    *allocPage(bin)*
1249       asigna a una página libre el tamaño de bloque ``bin`` y enlaza los
1250       nuevos bloques libres a la lista de libres correspondiente (análogo
1251       a ``assign_page()``).
1252
1253    *allocPages(n)*
1254       Busca ``n`` cantidad de páginas consecutivas libres (análoga
1255       a ``find_pages(n)``).
1256
1257    *malloc(size, bits)*
1258       asigna memoria para un objeto de tamaño ``size`` bytes. Análoga al
1259       algoritmo ``new(size, attr)`` presentado, excepto que introduce además
1260       un caché para no recalcular el tamaño de bloque necesario si se realizan
1261       múltiples asignaciones consecutivas de objetos del mismo tamaño y que la
1262       asignación de objetos pequeños no está separada en una función aparte.
1263
1264    *bigAlloc(size)*
1265       asigna un objeto grande (análogo a ``new_big()``). La implementación es
1266       mucho más compleja que la presentada en ``new_big()``, pero la semántica
1267       es la misma. La única diferencia es que esta función aprovecha que
1268       ``fullcollectshell()`` / ``fullcollect()`` retornan la cantidad de
1269       páginas liberadas en la recolección por lo que puede optimizar levemente
1270       el caso en que no se liberaron suficientes páginas para asignar el
1271       objeto grande y pasar directamente a crear un nuevo *pool*.
1272
1273    *free(p)*
1274       libera la memoria apuntada por ``p`` (análoga a ``delete()`` de la
1275       sección anterior).
1276
1277    Recordar que la ``pooltable`` siempre se mantiene ordenada según la
1278    dirección de la primera página.
1279
1280 Recolección
1281    *mark(pbot, ptop)*
1282       marca un rango de memoria. Este método es análogo al ``mark_range()``
1283       presentado en la sección :ref:`dgc_algo_mark`.
1284
1285    *fullcollectshell()*
1286       guarda los registros en el *stack* y llama a ``fullcollect()``. El
1287       algoritmo presentado en :ref:`dgc_algo_mark` es simbólico, ya que si los
1288       registros se apilaran en el *stack* dentro de otra función, al salir de
1289       esta se volverían a des-apilar, por lo tanto debe ser hecho en la misma
1290       función ``collect()`` o en una función que luego la llame (como en este
1291       caso).
1292
1293    *fullcollect(stackTop)*
1294       realiza la recolección de basura. Es análoga a ``collect()`` pero es
1295       considerablemente menos modular, todos los pasos se hacen directamente
1296       en esta función: marcado del *root set*, marcado iterativo del *heap*,
1297       barrido y reconstrucción de la lista de libres. Además devuelve la
1298       cantidad de páginas que se liberaron en la recolección, lo que permite
1299       optimizar levemente la función ``bigAlloc()``.
1300
1301
1302 Finalización
1303 ^^^^^^^^^^^^
1304 El recolector actual, por omisión, solamente efectúa una recolección al
1305 finalizar. Por lo tanto, no se ejecutan los destructores de todos aquellos
1306 objetos que son alcanzables desde el *root set* en ese momento. Existe la
1307 opción de no realizar una recolección al finalizar el recolector, pero no de
1308 finalizar *todos* los objetos (alcanzables o no desde el *root set*). Si bien
1309 la especificación de D_ permite este comportamiento (de hecho la
1310 especificación de D_ es tan vaga que permite un recolector que no llame jamás
1311 a ningún destructor), para el usuario puede ser una garantía muy débil
1312 y proveer finalización asegurada puede ser muy deseable.
1313
1314
1315 Memoria *encomendada*
1316 ^^^^^^^^^^^^^^^^^^^^^
1317 El algoritmo actual divide un *pool* en dos áreas: memoria *encomendada*
1318 (*committed* en inglés) y *no-encomendada*. Esto se debe a que originalmente
1319 el compilador de D_ DMD_ solo funcionaba en Microsoft Windows y este sistema
1320 operativo puede asignar memoria en dos niveles. Por un lado puede asignar al
1321 proceso un espacio de memoria (*address space*) pero sin asignarle la memoria
1322 correspondiente. En un paso posterior se puede *encomendar* la memoria (es
1323 decir, asignar realmente la memoria).
1324
1325 Para aprovechar esta característica el recolector diferencia estos dos
1326 niveles. Sin embargo, esta diferenciación introduce una gran complejidad (que
1327 se omitió en las secciones anteriores para facilitar la comprensión),
1328 y convierte lo que es una ventaja en un sistema operativo en una desventaja
1329 para todos los demás (ya que los cálculos extra se realizan pero sin ningún
1330 sentido). De hecho hay sistemas operativos, como Linux_, que realizan este
1331 trabajo automáticamente (la memoria no es asignada realmente al programa hasta
1332 que el programa no haga uso de ella; esta capacidad se denomina *overcommit*).
1333
1334 Como se vio en la figura :vref:`fig:dgc-pool`, lás páginas de un *pool* se
1335 dividen en *committed* y *uncommitted*. Siempre que el recolector recorre un
1336 *pool* en busca de una página o bloque, lo hace hasta la memoria *committed*,
1337 porque la *uncommitted* es como si jamás se hubiera pedido al sistema
1338 operativo a efectos prácticos. Además, al buscar páginas libres, si no se
1339 encuentran entre las *encomendadas* se intenta primero *encomendar* páginas
1340 nuevas antes de crear un nuevo *pool*.
1341
1342
1343 Sincronización
1344 ^^^^^^^^^^^^^^
1345 Si bien el recolector no es paralelo ni concurrente (ver :ref:`gc_art`),
1346 soporta múltiples *mutator*\ s. La forma de implementarlo es la más simple.
1347 Todas las operaciones sobre el recolector que se llaman externamente están
1348 sincronizadas utilizando un *lock* global (excepto cuando hay un solo hilo
1349 *mutator*, en cuyo caso se omite la sincronización). Esto afecta también a la
1350 asignación de memoria.
1351
1352
1353
1354 .. _dgc_good:
1355
1356 Características destacadas
1357 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1358
1359 Si bien el recolector en términos generales no se aleja mucho de un
1360 :ref:`marcado y barrido clásico <gc_mark_sweep>`, tiene algunas mejoras por
1361 sobre el algoritmo más básicos que vale la pena destacar:
1362
1363
1364 Organización del *heap*
1365 ^^^^^^^^^^^^^^^^^^^^^^^
1366 El *heap* está organizado de una forma que, si bien no emplea las técnicas más
1367 modernas que pueden observarse en el estado del arte (como :ref:`regiones
1368 <gc_free_list>`), es relativamente sofisticada. El esquema de *pools*
1369 y bloques permite disminuir considerablemente los problemas de *fragmentación*
1370 de memoria y evita búsquedas de *huecos* que pueden ser costosas (como
1371 *best-fit* [#dgcbestfit]_) o desperdiciar mucho espacio (como *first-fit*
1372 [#dgcfirstfit]_), logrando un buen equilibrio entre velocidad y espacio
1373 desperdiciado.
1374
1375 .. [#dgcbestfit] Las búsquedas de tipo *best-fit* son aquellas donde se busca
1376    el *hueco* en el *heap* (es decir, una región contínua de memoria
1377    libre) que mejor se ajuste al tamaño del objeto a asignar. Es decir, el
1378    *hueco* más pequeño lo suficientemente grande como para almacenarlo.
1379
1380 .. [#dgcfirstfit] Las búsquedas de tipo *first-fit* son aquellas donde se busca
1381    el primer *hueco* en el *heap* (es decir, una región contínua de memoria
1382    libre) que sea lo suficientemente grande como para almacenar el objeto
1383    a asignar.
1384
1385
1386 Fase de marcado iterativa
1387 ^^^^^^^^^^^^^^^^^^^^^^^^^
1388 A diferencia del algoritmo clásico recursivo, el algoritmo del recolector
1389 actual es iterativo. El algoritmo recursivo tiene un problema fundamental: se
1390 puede llegar a un desbordamiento de pila (o *stack overflow*). La cantidad de
1391 recursiones necesarias es, en el peor caso, :math:`O(|Live \thickspace set|)`
1392 (por ejemplo, si todas las celdas del *heap* formaran una lista simplemente
1393 enlazada). Hay muchas técnicas para lidiar con este problema, algunas que
1394 podrían aplicarse a D_ y otras que no (como *pointer reversal*) [JOLI96]_. El
1395 recolector actual, sin embargo, cambia complejidad en espacio por complejidad
1396 en tiempo, utilizando un algoritmo iterativo que es constante (:math:`O(1)`)
1397 en espacio, pero que requiere varias pasada sobre el *heap* en vez de una (la
1398 cantidad de pasadas es en el peor caso, al igual que la cantidad de
1399 recursiones del algoritmo recursivo, :math:`O(|Live \thickspace set|)`, pero
1400 cada pasada se realiza por sobre todo el *heap*).
1401
1402
1403 Conjuntos de bits para indicadores
1404 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1405 El algoritmo clásico propone almacenar en la propia celda la marca (para la
1406 fase de marcado) y otros indicadores. El algoritmo del recolector actual
1407 utiliza conjuntos de bits. Esto trae dos ventajas principales:
1408
1409 * Permite minimizar el espacio requerido, ya que de otra forma en general se
1410   desperdicia una palabra entera como cabecera de celda para guardar este tipo
1411   de información.
1412
1413 * Mejora la localidad de referencia, ya que los indicadores se escriben de
1414   forma muy compacta y en una región de memoria contigua que generalmente
1415   puede entrar en el cache o en pocas páginas de memoria acelerando
1416   considerablemente la fase de marcado.
1417
1418
1419 .. _dgc_debug:
1420
1421 Herramientas para depuración
1422 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1423
1424 El recolector provee algunas opciones para simplificar el diagnóstico
1425 y depuración de problemas, tanto del mismo recolector como del programa del
1426 usuario.
1427
1428 Las opciones más importantes son:
1429
1430
1431 ``MEMSTOMP``
1432    Su función es escribir un patrón determinado de bits en todos los bytes de
1433    un bloque de memoria según se haya:
1434
1435    * Pedido un bloque menor a una página (``0xF0``).
1436    * Pedido un bloque mayor a una página (``0xF1``).
1437    * Dejado de usar debido a un pedido de achicamiento de un bloque
1438      (``0xF2``).
1439    * Pedido más páginas debido a un pedido de agrandamiento de un bloque
1440      (``0xF0``).
1441    * Liberado intencionalmente por el usuario (``0xF2``).
1442    * Barrido (``0xF3``).
1443
1444    Esto permite al diagnosticar un problema saber, por ejemplo, si un
1445    determinado área de memoria fue recolectada recientemente, o liberada por
1446    el usuario, o recién adquirida, etc. con tan solo ver si un patrón de bits
1447    determinado está presente. Por supuesto puede existir *falsos positivos*
1448    pero su probabilidad es lo suficientemente baja como para que sea útil en
1449    la práctica.
1450
1451 ``SENTINEL``
1452    Su función detectar errores producidos por escribir más allá (o antes) del
1453    área de memoria solicitada y está implementado reservando un poco más de
1454    memoria de la que pide el usuario, devolviendo un puntero a un bloque
1455    ubicado dentro del bloque real reservado (en vez de al inicio) y finalmente
1456    escribiendo un patrón de bits en los extremos del borde real (ver figura
1457    :vref:`fig:sentinel`), de forma de poder verificar en distintas situación
1458    (por ejemplo al barrer el bloque) que esas áreas de más con los patrones de
1459    bits estén intactas. Esto permite detectar de forma temprana errores tanto
1460    en el recolector como en el programa del usuario.
1461
1462    .. fig:: fig:sentinel
1463
1464       Esquema de un bloque cuando está activada la opción ``SENTINEL``.
1465
1466       .. aafig::
1467
1468          |              |              |                              |        |
1469          +-- Palabra ---+-- Palabra ---+-- Tamaño bloque de usuario --+- Byte -+
1470          |              |              |                              |        |
1471
1472          +--------------+--------------+------------------------------+--------+
1473          |  Tamaño del  |     Pre      |                              |  Post  |
1474          |  bloque  de  |              |      Bloque de usuario       |        |
1475          |    usuario   |  0xF4F4F4F4  |                              |  0xF5  |
1476          +--------------+--------------+------------------------------+--------+
1477                                        A
1478                                        |
1479                    Puntero devuleto ---/
1480
1481 Ambas opciones son seleccionables sólo en tiempo de compilación del
1482 recolector, por lo que su utilidad real, al menos para el usuario, se ve
1483 severamente reducida.
1484
1485
1486 .. _dgc_bad:
1487
1488 Problemas y limitaciones
1489 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1490
1491 A continuación se presentan los principales problemas encontrados en la
1492 implementación actual del recolector de basura de D_. Estos problemas surgen
1493 principalmente de la observación del código y de aproximadamente tres años de
1494 participación y observación del grupo de noticias, de donde se obtuvieron los
1495 principales problemas percibidos por la comunidad que utiliza el lenguaje.
1496
1497
1498 Complejidad del código y documentación
1499 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1500 El análisis del código fue muy complicado debido a la falta de documentación
1501 y desorganización del código. Además se nota que el recolector ha sido escrito
1502 en una fase muy temprana y que a ido evolucionando a partir de ello de forma
1503 descuidada y sin ser rescrito nunca para aprovechar las nuevas características
1504 que el lenguaje fue incorporando (por ejemplo *templates*).
1505
1506 Estos dos problemas (código complicado y falta de documentación) producen un
1507 efecto de círculo vicioso, porque provocan que sea complejo entender el
1508 recolector actual y en consecuencia sea muy complicado escribir documentación
1509 o mejorarlo. Esto a su vez provoca que, al no disponer de una implementación
1510 de referencia sencilla, sea muy difícil implementar un recolector nuevo.
1511
1512 Este es, probablemente, la raíz de todos los demás problemas del recolector
1513 actual. Para ilustrar la dimensión del problema se presenta la implementación
1514 real de la función ``bigAlloc()``::
1515
1516     /**
1517      * Allocate a chunk of memory that is larger than a page.
1518      * Return null if out of memory.
1519      */
1520     void *bigAlloc(size_t size)
1521     {
1522         Pool*  pool;
1523         size_t npages;
1524         size_t n;
1525         size_t pn;
1526         size_t freedpages;
1527         void*  p;
1528         int    state;
1529
1530         npages = (size + PAGESIZE - 1) / PAGESIZE;
1531
1532         for (state = 0; ; )
1533         {
1534             // This code could use some refinement when repeatedly
1535             // allocating very large arrays.
1536
1537             for (n = 0; n < npools; n++)
1538             {
1539                 pool = pooltable[n];
1540                 pn = pool.allocPages(npages);
1541                 if (pn != OPFAIL)
1542                     goto L1;
1543             }
1544
1545             // Failed
1546             switch (state)
1547             {
1548             case 0:
1549                 if (disabled)
1550                 {   state = 1;
1551                     continue;
1552                 }
1553                 // Try collecting
1554                 freedpages = fullcollectshell();
1555                 if (freedpages >= npools * ((POOLSIZE / PAGESIZE) / 4))
1556                 {   state = 1;
1557                     continue;
1558                 }
1559                 // Release empty pools to prevent bloat
1560                 minimize();
1561                 // Allocate new pool
1562                 pool = newPool(npages);
1563                 if (!pool)
1564                 {   state = 2;
1565                     continue;
1566                 }
1567                 pn = pool.allocPages(npages);
1568                 assert(pn != OPFAIL);
1569                 goto L1;
1570             case 1:
1571                 // Release empty pools to prevent bloat
1572                 minimize();
1573                 // Allocate new pool
1574                 pool = newPool(npages);
1575                 if (!pool)
1576                     goto Lnomemory;
1577                 pn = pool.allocPages(npages);
1578                 assert(pn != OPFAIL);
1579                 goto L1;
1580             case 2:
1581                 goto Lnomemory;
1582             default:
1583                 assert(false);
1584             }
1585         }
1586
1587       L1:
1588         pool.pagetable[pn] = B_PAGE;
1589         if (npages > 1)
1590             cstring.memset(&pool.pagetable[pn + 1], B_PAGEPLUS, npages - 1);
1591         p = pool.baseAddr + pn * PAGESIZE;
1592         cstring.memset(cast(char *)p + size, 0, npages * PAGESIZE - size);
1593         debug (MEMSTOMP) cstring.memset(p, 0xF1, size);
1594         //debug(PRINTF) printf("\tp = %x\n", p);
1595         return p;
1596
1597       Lnomemory:
1598         return null; // let mallocNoSync handle the error
1599     }
1600
1601 Se recuerda que la semántica de dicha función es la misma que la de la función
1602 ``new_big()`` presentada en :ref:`dgc_algo_alloc`.
1603
1604 Además, como se comentó en la sección anterior, los algoritmos en la
1605 implementación real son considerablemente menos modulares que los presentados
1606 en la sección :ref:`dgc_algo`. Por ejemplo, la función ``fullcollect()`` son
1607 300 líneas de código.
1608
1609
1610 Memoria *encomendada*
1611 ^^^^^^^^^^^^^^^^^^^^^
1612 Como se comentó en la sección anterior, diferenciar entre memoria
1613 *encomendada* de memoria *no-encomendada* es complejo y levemente costoso (en
1614 particular para sistemas operativos que no hacen esta distinción, al menos
1615 explícitamente, donde no hay ningún beneficio en realizar esta distinción).
1616
1617 Incluso para Microsoft Windows, la ventaja de realizar esta distinción es
1618 discutible.
1619
1620
1621 Precisión
1622 ^^^^^^^^^
1623 Este fue históricamente uno de los problemas principales del recolector de D_
1624 [NGD46407]_ [NGD35364]_. Sin embargo, desde que, en la versión 1.001, se ha
1625 incorporado la capacidad de marcar un bloque como de datos puros (no contiene
1626 punteros, el atributo ``NO_SCAN``) [NGA6842]_, la gravedad de esos problemas ha
1627 disminuido considerablemente, aunque siguieron reportándose problemas más
1628 esporádicamente [NGD54084]_ [NGL13744]_.
1629
1630 De todas maneras queda mucho lugar para mejoras, y es un tema recurrente en el
1631 grupo de noticias de D_ y se han discutido formas de poder hacer que, al menos
1632 el *heap* sea preciso [NGD44607]_ [NGD29291]_. Además se mostró un interés
1633 general por tener un recolector más preciso [NGDN87831]_, pero no han habido
1634 avances al respecto.
1635
1636 Otra forma de minimizar los efectos de la falta de precisión que se ha
1637 sugerido reiteradamente en el grupo es teniendo la
1638 posibilidad de indicar cuando no pueden haber punteros interiores a un bloque
1639 [NGD89394]_ [NGD71869]_. Esto puede ser de gran utilidad para objetos grandes
1640 y en particular para mejorar la implementación de de arreglos asociativos.
1641
1642
1643 Referencias débiles
1644 ^^^^^^^^^^^^^^^^^^^
1645 El recolector actual no dispone de soporte de *referencias débiles*
1646 [#dgcweakref]_, sin embargo hay una demanda apreciable [NGD86840]_ [NGD13301]_
1647 [NGL8264]_ [NGD69761]_ [NGD74624]_ [NGD88065]_.
1648
1649 .. [#dgcweakref] Una referencia débil (o *weak reference* en inglés) es
1650    aquella que que no protege al objeto referenciado de ser reciclado por el
1651    recolector.
1652
1653 Para cubrir esta demanda, se han implementado soluciones como biblioteca para
1654 suplir la inexistencia de una implementación oficial [NGA9103]_.
1655
1656 Sin embargo éstas son en general poco robustas, extremadamente dependientes
1657 de la implementación del recolector y, en general, presentan problemas muy
1658 sutiles [NGD88065]_. Por esta razón se ha discutido la posibilidad de incluir
1659 la implementación de *referencias débiles* como parte del lenguaje
1660 [NGD88559]_.
1661
1662
1663 Concurrencia
1664 ^^^^^^^^^^^^
1665 El soporte actual de concurrencia, en todos sus aspectos, es muy primitivo. El
1666 recolector apenas soporta múltiples *mutators* pero con un nivel de
1667 sincronización excesivo.
1668
1669 Se ha sugerido en el pasado el uso de *pools* y listas de libres específicos
1670 de hilos, de manera de disminuir la contención, al menos para la asignación de
1671 memoria [NGD75952]_ [NGDN87831]_.
1672
1673 Además se ha mostrado un interés por tener un nivel de concurrencia aún mayor
1674 en el recolector, para aumentar la concurrencia en ambientes *multi-core* en
1675 general pero en particular para evitar grandes pausas en programas con
1676 requerimientos de tiempo real, históricamente una de las principales críticas
1677 al lenguaje [NGDN87831]_ [NGL3937]_ [NGD22968]_ [NGA15246]_ [NGD5622]_
1678 [NGD2547]_ [NGD18354]_.
1679
1680
1681 Finalización
1682 ^^^^^^^^^^^^
1683 El recolector actual no garantiza la finalización de objetos. En particular
1684 los objetos no son finalizados (es decir, no se llama a sus destructores)
1685 si aún alcanzables desde el *root set* cuando el programa termina. Cabe
1686 destacar que esto puede darse porque hay una referencia real desde el *root
1687 set* (en cuyo caso queda bajo el control del usuario) pero también, dado que
1688 el *root set* se visita de forma conservativa, se puede deber a un falso
1689 positivo, en cuyo caso la omisión de la finalización queda por completo fuera
1690 del control del usuario (y lo que es aún peor, el usuario no puede ser
1691 siquiera notificado de esta anomalía).
1692
1693 Si bien la especificación de D_ no requiere esta capacidad (de hecho,
1694 rigurosamente hablando la especificación de D_ no garantiza la finalización de
1695 objetos bajo ninguna circunstancia), no hay mayores problemas para implementar
1696 un recolector que de este tipo de garantías [NGD88298]_.
1697
1698 Además los objetos pueden ser finalizados tanto determinísticamente
1699 (utilizando ``delete`` o ``scope``; ver secciones :ref:`d_low_level`
1700 y :ref:`d_dbc`) como no determinísticamente (cuando son finalizados por el
1701 recolector). En el primer caso se puede, por ejemplo, acceder sus atributos
1702 u otra memoria que se conozca *viva*, mientras que en el segundo no. Sin
1703 embargo un destructor no puede hacer uso de esta distinción, haciendo que la
1704 finalización determinística tenga a fines prácticos las mismas restricciones
1705 que la finalización no determinística. Es por esto que se ha sugerido permitir
1706 al destructor distinguir estos dos tipos de finalización [NGD89302]_.
1707
1708
1709 Eficiencia
1710 ^^^^^^^^^^
1711 El rendimiento en general del recolector es una de las críticas frecuentes. Si
1712 bien hay muchos problemas que han sido resueltos, en especial por la inclusión
1713 de un mínimo grado de precisión en la versión 1.001, en la actualidad se
1714 siguen encontrando en el grupo de noticias críticas respecto a esto
1715 [NGD43991]_ [NGD67673]_ [NGD63541]_ [NGD90977]_.
1716
1717 La principal causa del bajo rendimiento del recolector actual es,
1718 probablemente, lo simple de su algoritmo principal de recolección. Más allá de
1719 una organización del *heap* moderadamente apropiada y de utilizar conjuntos de
1720 bits para la fase de marcado, el resto del algoritmo es casi la versión más
1721 básica de marcado y barrido. Hay mucho lugar para mejoras en este sentido.
1722
1723
1724 Configurabilidad
1725 ^^^^^^^^^^^^^^^^
1726 Si bien el recolector actual tiene algunas características configurables,
1727 todas son seleccionables sólo en tiempo de compilación del recolector (no del
1728 programa del usuario), como por ejemplo las opciones descriptas en
1729 :ref:`dgc_debug`. Por lo tanto, a nivel práctico, es como si no tuviera
1730 posibilidad alguna de ser configurado por el usuario, ya que no es parte del
1731 ciclo de desarrollo normal el recompilar el recolector o *runtime* de un
1732 lenguaje.
1733
1734 Dado que es imposible que un recolector sea óptimo para todo tipo de
1735 programas, es muy deseable permitir una configuración de parámetros del
1736 recolector que permitan al usuario ajustarlo a las necesidades particulares de
1737 sus programas.
1738
1739
1740 .. _dgc_bad_ocup:
1741
1742 Factor de ocupación del *heap*
1743 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1744 Otro problema potencialmente importante del recolector actual es que no se
1745 tiene ningún cuidado con respecto a que, luego de una recolección, se haya
1746 recuperado una buena parte del *heap*. Por lo tanto, en casos extremos, el
1747 recolector tiene que hacer una recolección por cada petición de memoria, lo
1748 que es extremadamente ineficiente.
1749
1750 Para evitar esto, habría que usar algún esquema para evaluar cuando una
1751 recolección no fue lo suficientemente *exitosa* y en ese caso pedir más
1752 memoria al sistema operativo.
1753
1754
1755 Detalles
1756 ^^^^^^^^
1757 Finalmente hay varios detalles en la implementación actual que podrían
1758 mejorarse:
1759
1760 Listas de libres
1761    hay 12 listas de libres, como para guardar bloques de tamaño de ``B_16``
1762    a ``B_2048``, ``B_PAGE``, ``B_PAGEPLUS``, ``B_UNCOMMITTED`` y ``B_FREE``;
1763    sin embargo solo tienen sentido los bloques de tamaño ``B_16``
1764    a ``B_2048``, por lo que 4 de esas listas no se utilizan.
1765
1766 Conjuntos de bits para indicadores
1767    los indicadores para la fase de marcado y otras propiedades de un bloque
1768    son almacenados en conjuntos de bits que almacenan los indicadores de todos
1769    los bloques de un *pool*. Si bien se ha mencionado esto como una ventaja,
1770    hay lugar todavía como para algunas mejoras. Como un *pool* tiene páginas
1771    con distintos tamaños de bloque, se reserva una cantidad de bits igual a la
1772    mayor cantidad posible de bloques que puede haber en el *pool*; es decir,
1773    se reserva 1 bit por cada 16 bytes del *pool*. Para un *pool* de 1 MiB
1774    (tamaño mínimo), teniendo en cuenta que se utilizan 5 conjuntos de bits
1775    (``mark``, ``scan``, ``finals``, ``freebits`` y ``noscan``), se utilizan 40
1776    KiB de memoria para conjuntos de bits (un 4% de *desperdicio* si, por
1777    ejemplo, ese *pool* estuviera destinado por completo a albergar un solo
1778    objeto grande; lo que equivaldría al 2560 objetos de 16 bytes
1779    desperdiciados en bits inutilizados).
1780
1781 Repetición de código
1782    Hay algunos fragmentos de código repetidos innecesariamente. Por ejemplo en
1783    varios lugares se utilizan arreglos de tamaño variable que se implementan
1784    repetidas veces (en general como un puntero al inicio del arreglo más el
1785    tamaño actual del arreglo más el tamaño de la memoria total asignada
1786    actualmente). Esto es propenso a errores y difícil de mantener.
1787
1788 Uso de señales
1789    el recolector actual utiliza las señales del sistema operativo ``SIGUSR1``
1790    y ``SIGUSR2`` para pausar y reanudar los hilos respectivamente. Esto
1791    puede traer inconvenientes a usuarios que desean utilizar estas
1792    señales en sus programas (o peor aún, si interactúan con bibliotecas
1793    de C que hacen uso de estas señales) [NGD5821]_.
1794
1795 Marcado iterativo
1796    si bien esto se mencionó como algo bueno del recolector actual, es un
1797    compromiso entre tiempo y espacio, y puede ser interesante analizar otros
1798    métodos para evitar la recursión que no requieran tantas pasadas sobre el
1799    *heap*.
1800
1801
1802 .. include:: links.rst
1803
1804 .. vim: set ts=3 sts=3 sw=3 et tw=78 spelllang=es :