X-Git-Url: https://git.llucax.com/z.facultad/75.00/informe.git/blobdiff_plain/482caf6211b4e4bc4fc99907eaf3d364a7348984..409ef528d2b45bdcbcd6868b3d0f82c1edf8e748:/source/dgc.rst

diff --git a/source/dgc.rst b/source/dgc.rst
index f087aef..370b664 100644
--- a/source/dgc.rst
+++ b/source/dgc.rst
@@ -238,9 +238,9 @@ dicho objeto.
    para indicar la continuación de un objeto grande (que ocupan más de una
    página).
 
-.. fig:: fig:dgc-org
+.. flt:: fig:dgc-org
 
-   Organización del *heap* del recolector de basura actual de D.
+   Organización del *heap* del recolector de basura actual de D
 
    Organización del *heap*. En este ejemplo todos los *pools* tienen 2 páginas
    excepto el *pool* 2 que tiene una sola.  El tamaño de bloque que almacena
@@ -304,9 +304,9 @@ parte de una :ref:`lista de libres <gc_free_list>` (ver figura
 :vref:`fig:dgc-free-list`). Esto permite asignar objetos relativamente
 pequeños de forma bastante eficiente.
 
-.. fig:: fig:dgc-free-list
+.. flt:: fig:dgc-free-list
 
-   Ejemplo de listas de libres.
+   Ejemplo de listas de libres
 
    .. digraph:: dgc_free_list
 
@@ -1058,9 +1058,9 @@ C ``malloc()``, ``realloc()`` y ``free()`` directamente.
 La estructura ``Pool`` está compuesta por los siguientes atributos (ver figura
 :vref:`fig:dgc-pool`):
 
-.. fig:: fig:dgc-pool
+.. flt:: fig:dgc-pool
 
-   Vista gráfica de la estructura de un *pool* de memoria.
+   Vista gráfica de la estructura de un *pool* de memoria
 
    .. aafig::
       :scale: 120
@@ -1480,9 +1480,9 @@ Las opciones más importantes son:
    bits estén intactas. Esto permite detectar de forma temprana errores tanto
    en el recolector como en el programa del usuario.
 
-   .. fig:: fig:sentinel
+   .. flt:: fig:sentinel
 
-      Esquema de un bloque cuando está activada la opción ``SENTINEL``.
+      Esquema de un bloque cuando está activada la opción ``SENTINEL``
 
       .. aafig::
          :textual:
@@ -1656,7 +1656,7 @@ esporádicamente [NGD54084]_ [NGL13744]_.
 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
@@ -1694,13 +1694,13 @@ sincronización excesivo.
 
 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]_.
 
 
@@ -1917,8 +1917,8 @@ base del algoritmo del recolector de basura actual.
 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