De todas maneras queda mucho lugar para mejoras, y es un tema recurrente en el
grupo de noticias de D_ y se han discutido formas de poder hacer que, al menos
el *heap* sea preciso [NGD44607]_ [NGD29291]_. Además se mostró un interés
-general por tener un recolector más preciso [NGDN87831]_, pero no han habido
+general por tener un recolector más preciso [NGD87831]_, pero no han habido
avances al respecto.
Otra forma de minimizar los efectos de la falta de precisión que se ha
Se ha sugerido en el pasado el uso de *pools* y listas de libres específicos
de hilos, de manera de disminuir la contención, al menos para la asignación de
-memoria [NGD75952]_ [NGDN87831]_.
+memoria [NGD75952]_ [NGD87831]_.
Además se ha mostrado un interés por tener un nivel de concurrencia aún mayor
en el recolector, para aumentar la concurrencia en ambientes *multi-core* en
general pero en particular para evitar grandes pausas en programas con
requerimientos de tiempo real, históricamente una de las principales críticas
-al lenguaje [NGDN87831]_ [NGL3937]_ [NGD22968]_ [NGA15246]_ [NGD5622]_
+al lenguaje [NGD87831]_ [NGL3937]_ [NGD22968]_ [NGA15246]_ [NGD5622]_
[NGD2547]_ [NGD18354]_.
En general en la comunidad de D_ no hay mayores críticas al marcado y barrido
en sí, si no más bien a problemas asociados a la implementación actual,
principalmente a las grandes pausas o la falta de :ref:`precisión
-<gc_conserv>` [NGD54084]_ [NGL13744]_ [NGD44607]_ [NGD29291]_ [NGDN87831]_
-[NGDN87831]_ [NGL3937]_ [NGD22968]_ [NGA15246]_ [NGD5622]_ [NGD2547]_
+<gc_conserv>` [NGD54084]_ [NGL13744]_ [NGD44607]_ [NGD29291]_ [NGD87831]_
+[NGD87831]_ [NGL3937]_ [NGD22968]_ [NGA15246]_ [NGD5622]_ [NGD2547]_
[NGD18354]_.
Esta familia de algoritmos se adapta bien a los requerimientos principales de