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: SIN EMPEZAR, REVISAR LO HECHO
   8
   9
  10 .. _dgc:
  11
  12 Recolección de basura en D
  13 ============================================================================
  14
  15 TODO
  16
  17
  18
  19 Dificultades para recolectar basura en D
  20 ----------------------------------------------------------------------------
  21
  22 TODO
  23
  24
  25
  26 .. _dgc_actual:
  27
  28 Recolector de basura actual de D
  29 ----------------------------------------------------------------------------
  30
  31 TODO
  32
  33
  34
  35 Diseño
  36 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  37
  38 .. Acá iría básicamente lo que escribí en el blog sobre la implmentación
  39    actual
  40
  41 TODO
  42
  43
  44
  45 Implementación
  46 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  47
  48 .. Acá diría por qué hay que reescribirlo para usar lo que está
  49
  50 TODO
  51
  52
  53
  54 Problemas y limitaciones
  55 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  56
  57 TODO
  58
  59
  60
  61
  62 Como se ha visto, D_ es un lenguaje de programación muy completo, pero aún
  63 tiene algunos aspectos inconclusos. Su recolector de basura está en un estado
  64 de evolución muy temprana. Se trata de un marcado y barrido (*mark and sweep*)
  65 conservativo que, en ciertas circunstancias, no se comporta como es debido, ya
  66 que revisa toda la memoria del programa en busca de referencias a objetos en
  67 el *heap* (en vez de revisar sólo las partes que almacenan punteros). Esto
  68 produce que, en ciertos casos, por ejemplo al almacenar arreglos de número
  69 o *strings* en la pila, el recolector de basura se encuentre con *falsos
  70 positivos*, pensando que un área del *heap* está siendo utilizada cuando en
  71 realidad el puntero que hacía referencia a ésta no era tal. Este efecto puede
  72 llevar a la pérdida de memoria masiva, llegando al límite de que eventualmente
  73 el sistema operativo tenga que matar al programa por falta de memoria
  74 [DNG46407]_. Aún cuando el programa no tenga estos problemas de por sí, por
  75 usar datos que no pueden ser confundidos con direcciones de memoria, este
  76 problema podría ser explotado por ataques de seguridad, inyectando valores que
  77 sí sean punteros válidos y provocando el efecto antes mencionado que deriva en
  78 la terminación abrupta del programa [DNG35364]_.  Finalmente, a estos problemas
  79 se suman los problemas de *performance* [DNG43991]_.
  80
  81 Es difícil que D_ pueda ser un lenguaje de programación exitoso si no provee un
  82 recolector de basura eficiente y que realmente evite la pérdida masiva de
  83 memoria. Por otro lado, D_ podría atraer a una base de usuarios mucho más
  84 amplia, si la gama de estrategias de recolección es más amplia, pudiendo lograr
  85 adaptarse a más casos de uso sin llegar al límite de tener que caer en el
  86 manejo explícito de memoria y perder por completo las ventajas de la
  87 recolección de basura (con la consecuencia ya mencionada de que el manejo de
  88 memoria tenga que pasar a ser parte de las interfaces y la complejidad que esto
  89 agrega al diseño -y uso- de una biblioteca).
  90
  91
  92
  93 Soluciones Propuestas
  94
  95 Para poder implementar un recolector de basura no conservativo es necesario
  96 disponer de un soporte de reflexión (en tiempo de compilación [DNG44607]_ y de
  97 ejecución [DNG29291]_) bastante completo . De otra forma es imposible
  98 distinguir si un área de memoria de la pila es utilizada como un puntero o como
  99 un simple conjunto de datos. D_ provee algún grado de reflexión, pero muy
 100 limitado como para poder obtener este tipo de información. Ya hay un plan para
 101 agregar mayores capacidades de reflexibilidad [DNG6842]_, y un pequeño avance
 102 en este sentido en la `versión 1.001`_, pero con algunos problemas [DNG6890]_
 103 [DNG6893]_.
 104
 105 .. _`versión 1.001`: http://www.digitalmars.com/d/changelog.html#new1_001
 106
 107 Se han propuesto otros métodos e implementaciones de recolector de basura, por
 108 ejemplo colectores con movimiento (*moving collectors*) [DNG42557]_ y conteo de
 109 referencias [DNG38689]_. Pero D_ es un lenguaje muy particular en cuanto a la
 110 recolección de basura (al permitir :ref:d_low_level hay muchas consideraciones
 111 a las que otros lenguajes no deben enfrentarse) y no es sencillo pensar en
 112 otras implementaciones sin hacer modificaciones de base al lenguaje.
 113
 114
 115
 116 Problemas para Implementar Colectores con Movimiento
 117
 118 El principal problema es la capacidad de D_ de manipular punteros y otras
 119 estructuras de bajo nivel, como uniones. O incluso la capacidad de interactuar
 120 con C. Al mover un objeto de un área de memoria a otro, es necesario actualizar
 121 todos los punteros que apuntan a éste. En D_ esta tarea no es trivial
 122 [DNG42564]_
 123
 124
 125
 126 Problemas para Implementar Conteo de Referencias
 127
 128 Este tipo de recolectores reparten la carga de la recolección de forma uniforme
 129 a lo largo (y a la par) de la ejecución del programa. El problema principal
 130 para implementar este tipo de recolección es la necesidad de soporte en el
 131 compilador (cada asignación debe ser acompañada por el incremento/decremento de
 132 contadores de referencia), a menos que se implemente en una biblioteca. Por
 133 otro lado, características como el rebanado de arreglos (ver :ref:d_high_level)
 134 son difíciles de proveer con el conteo de referencias, entre otros problemas
 135 [DNG38704]_.
 136
 137
 138 .. include:: links.rst
 139
 140 .. vim: set ts=3 sts=3 sw=3 et tw=78 :