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