]> git.llucax.com Git - z.facultad/75.00/informe.git/commitdiff
Eliminar prefijo "ref_" de nombres de referencias
authorLeandro Lucarella <llucax@gmail.com>
Sat, 6 Jun 2009 21:26:12 +0000 (18:26 -0300)
committerLeandro Lucarella <llucax@gmail.com>
Sat, 6 Jun 2009 21:46:25 +0000 (18:46 -0300)
No son necesarios y hacen más tedioso redactar texto con referencias.

source/conclusion.rst
source/d.rst
source/dgc.rst
source/gc.rst
source/intro.rst
source/referencias.rst
source/resumen.rst
source/solucion.rst
source/viabilidad.rst

index f25361c2c3b3b0777d84d83b186162dd7eb8bb3d..8016852a3a8661cd9b0eccef9b5450f62abb61ff 100644 (file)
@@ -5,7 +5,7 @@
    ESTADO: SIN EMPEZAR
 
 
    ESTADO: SIN EMPEZAR
 
 
-.. _ref_conclusion:
+.. _conclusion:
 
 Conclusión
 ============================================================================
 
 Conclusión
 ============================================================================
index b4af95dc42de9436f3147fea3bec2b502c025eeb..15334bd9a1bdde8b80caf259b7c7981b25303dfa 100644 (file)
@@ -5,7 +5,7 @@
    ESTADO: TERMINADO
 
 
    ESTADO: TERMINADO
 
 
-.. _ref_d:
+.. _d_lang:
 
 El lenguaje de programación D
 ============================================================================
 
 El lenguaje de programación D
 ============================================================================
@@ -174,7 +174,7 @@ agrupadas por unidades funcional o paradigmas que soporta:
 
 
 
 
 
 
-.. _ref_d_generic:
+.. _d_generic:
 
 Programación genérica y meta-programación
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Programación genérica y meta-programación
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -426,7 +426,7 @@ Expresiones ``is``:
 
 
 
 
 
 
-.. _ref_d_low_level:
+.. _d_low_level:
 
 Programación de bajo nivel (*system programming*)
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Programación de bajo nivel (*system programming*)
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -501,7 +501,7 @@ Objetos y arreglos *livianos*:
       gettimeofday(&tv, null);
 
 Rendimiento:
       gettimeofday(&tv, null);
 
 Rendimiento:
-   la :ref:`ref_d_generic` permite realizar muchas optimizaciones ya que se
+   la :ref:`d_generic` permite realizar muchas optimizaciones ya que se
    resuelve en tiempo de compilación y por lo tanto aumentando la
    *performance* en la ejecución.
 
    resuelve en tiempo de compilación y por lo tanto aumentando la
    *performance* en la ejecución.
 
@@ -524,7 +524,7 @@ Control de alineación de miembros de una estructura:
 
 
 
 
 
 
-.. _ref_d_high_level:
+.. _d_high_level:
 
 Programación de alto nivel
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Programación de alto nivel
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -533,7 +533,7 @@ Programa de alto nivel se refiere a construcciones más avanzadas que un
 loop. Expresiones semánticamente más ricas que permiten mayor expresividad
 al programador o le permiten focalizarse de mejora manera en los algoritmos
 independizándose del *hardware* o de como funciona una computadora. Es
 loop. Expresiones semánticamente más ricas que permiten mayor expresividad
 al programador o le permiten focalizarse de mejora manera en los algoritmos
 independizándose del *hardware* o de como funciona una computadora. Es
-exactamente el opuesto a :ref:`ref_d_low_level`.
+exactamente el opuesto a :ref:`d_low_level`.
 
 En general estas características tiene como efecto secundario una mejora de
 la productividad de los programadores. D_ adopta herramientas de muchos
 
 En general estas características tiene como efecto secundario una mejora de
 la productividad de los programadores. D_ adopta herramientas de muchos
index cb595941d03420994d15a30dcfcb7f56d0442134..929d48c46a30d2b09cf1cfffa15470958e277d22 100644 (file)
@@ -7,7 +7,7 @@
    ESTADO: SIN EMPEZAR, REVISAR LO HECHO
 
 
    ESTADO: SIN EMPEZAR, REVISAR LO HECHO
 
 
-.. _ref_dgc:
+.. _dgc:
 
 Recolección de basura en D
 ============================================================================
 
 Recolección de basura en D
 ============================================================================
@@ -23,7 +23,7 @@ TODO
 
 
 
 
 
 
-.. _ref_dgc_actual:
+.. _dgc_actual:
 
 Recolector de basura actual de D
 ----------------------------------------------------------------------------
 
 Recolector de basura actual de D
 ----------------------------------------------------------------------------
index 7b36319fdfcaf9b0761b3bf0cdf884f2d6ec26b7..c32bfee3a98cf8aa0a97ada388a4c5778d7e7981 100644 (file)
@@ -5,14 +5,14 @@
    ESTADO: TERMINADO
 
 
    ESTADO: TERMINADO
 
 
-.. _ref_gc:
+.. _gc:
 
 Recolección de basura
 ============================================================================
 
 
 
 
 Recolección de basura
 ============================================================================
 
 
 
-.. _ref_gc_intro:
+.. _gc_intro:
 
 Introducción
 ----------------------------------------------------------------------------
 
 Introducción
 ----------------------------------------------------------------------------
@@ -195,7 +195,7 @@ normalmente se lo llama *mutator* (mutador).
 
 
 
 
 
 
-.. _ref_gc_intro_mark:
+.. _gc_intro_mark:
 
 Recorrido del grafo de conectividad
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Recorrido del grafo de conectividad
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -594,15 +594,15 @@ dejando sin marcar solamente las celdas *basura* (en blanco).
 
 
 
 
 
 
-.. _ref_gc_intro_tricolor:
+.. _gc_intro_tricolor:
 
 Abstracción tricolor
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Muchos algoritmos utilizan tres colores para realizar el marcado. El tercer
 color, gris generalmente, indica que una celda debe ser visitada. Esto
 
 Abstracción tricolor
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Muchos algoritmos utilizan tres colores para realizar el marcado. El tercer
 color, gris generalmente, indica que una celda debe ser visitada. Esto
-permite algoritmos :ref:`concurrentes <ref_gc_concurrent>`
-e :ref:`incrementales <ref_gc_inc>`, además de otro tipo de optimizaciones.
+permite algoritmos :ref:`concurrentes <gc_concurrent>`
+e :ref:`incrementales <gc_inc>`, además de otro tipo de optimizaciones.
 Entonces, lo que plantea esta abtracción es una nueva partición del heap al
 momento de marcar, esta vez son 3 porciones: blanca, gris y negra.
 
 Entonces, lo que plantea esta abtracción es una nueva partición del heap al
 momento de marcar, esta vez son 3 porciones: blanca, gris y negra.
 
@@ -639,7 +639,7 @@ por sí ya presenta una ventaja sobre el marcado *bicolor*.
 
 
 
 
 
 
-.. _ref_gc_intro_services:
+.. _gc_intro_services:
 
 Servicios
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Servicios
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -704,7 +704,7 @@ siguientes:
    cambio en la conectividad del grafo, la eliminación de una arista
    (análogo a :math:`update(ref, null)` pero sin proporcionar información
    sobre la arista a eliminar). Esto es generalmente útil solo en
    cambio en la conectividad del grafo, la eliminación de una arista
    (análogo a :math:`update(ref, null)` pero sin proporcionar información
    sobre la arista a eliminar). Esto es generalmente útil solo en
-   :ref:`conteo de referencias <ref_gc_rc>`. Para otros recolectores puede
+   :ref:`conteo de referencias <gc_rc>`. Para otros recolectores puede
    significar que el usuario asegura que no hay más referencias a esta
    celda, es decir, análogo a eliminar el conjunto de aristas
    :math:`\big\lbrace (v, w) \in A , v \in Live \thickspace set , w \in
    significar que el usuario asegura que no hay más referencias a esta
    celda, es decir, análogo a eliminar el conjunto de aristas
    :math:`\big\lbrace (v, w) \in A , v \in Live \thickspace set , w \in
@@ -723,7 +723,7 @@ usuario también.
 
 
 
 
 
 
-.. _ref_gc_classic:
+.. _gc_classic:
 
 Algoritmos clásicos
 ----------------------------------------------------------------------------
 
 Algoritmos clásicos
 ----------------------------------------------------------------------------
@@ -735,14 +735,14 @@ más simples a fin de facilitar la comprensión conceptual.
 
 
 
 
 
 
-.. _ref_gc_rc:
+.. _gc_rc:
 
 Conteo de referencias
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Se trata del algoritmo más antiguo de todos, implementado por primera vez
 por `John McCarthy`_ para Lisp_ a finales de 1950. Se trata de un método
 
 Conteo de referencias
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Se trata del algoritmo más antiguo de todos, implementado por primera vez
 por `John McCarthy`_ para Lisp_ a finales de 1950. Se trata de un método
-:ref:`directo <ref_gc_direct>` e :ref:`incremental <ref_gc_inc>` por
+:ref:`directo <gc_direct>` e :ref:`incremental <gc_inc>` por
 naturaleza, ya que distribuye la carga de la recolección de basura durante
 toda la ejecución del programa, cada vez que el *mutator* cambia la
 conectividad de algún nodo del grafo de conectividad.
 naturaleza, ya que distribuye la carga de la recolección de basura durante
 toda la ejecución del programa, cada vez que el *mutator* cambia la
 conectividad de algún nodo del grafo de conectividad.
@@ -814,7 +814,7 @@ siguientes (acompañadas de una implementación básica)::
 
 
 
 
 
 
-.. _ref_gc_rc_cycles:
+.. _gc_rc_cycles:
 
 Ciclos
 ^^^^^^
 
 Ciclos
 ^^^^^^
@@ -849,7 +849,7 @@ la versión 5.3 (todavía no liberada al momento de escribir este documento)
 [PHP081]_.
 
 
 [PHP081]_.
 
 
-.. _ref_gc_rc_example:
+.. _gc_rc_example:
 
 Ejemplo
 ^^^^^^^
 
 Ejemplo
 ^^^^^^^
@@ -1607,7 +1607,7 @@ figura :vref:`fig:gc-rc-cycle`).
 
 
 
 
 
 
-.. _ref_gc_mark_sweep:
+.. _gc_mark_sweep:
 
 Marcado y barrido
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Marcado y barrido
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -1616,7 +1616,7 @@ Este algoritmo es el más parecido a la teoría sobre recolección de basura.
 Consiste en realizar la recolección en 2 fases: marcado y barrido. La primera
 fase consiste en el proceso de marcar el grafo de conectividad del *heap* para
 descubrir qué celdas son alcanzables desde el *root set*, tal y como se
 Consiste en realizar la recolección en 2 fases: marcado y barrido. La primera
 fase consiste en el proceso de marcar el grafo de conectividad del *heap* para
 descubrir qué celdas son alcanzables desde el *root set*, tal y como se
-describió en :ref:`ref_gc_intro_mark`.
+describió en :ref:`gc_intro_mark`.
 
 Una vez marcadas todas las celdas, se sabe que las celdas *blancas* son
 *basura*, por lo tanto el paso que queda es el *barrido* de estas celdas,
 
 Una vez marcadas todas las celdas, se sabe que las celdas *blancas* son
 *basura*, por lo tanto el paso que queda es el *barrido* de estas celdas,
@@ -1652,19 +1652,19 @@ A continuación se presentan los servicios básicos de este algoritmo::
             free(cell)
 
 El algoritmo ``mark_sweep()`` es exactamente igual al presentado en
             free(cell)
 
 El algoritmo ``mark_sweep()`` es exactamente igual al presentado en
-:ref:`ref_gc_intro_mark`. Es preciso notar que la fase de barrido
+:ref:`gc_intro_mark`. Es preciso notar que la fase de barrido
 (``sweep_phase()``) debe tener una comunicación extra con el *low level
 allocator* para poder obtener todas las celdas de memoria que existen en el
 *heap*.
 
 A diferencia del conteo de referencias, este algoritmo es :ref:`indirecto
 (``sweep_phase()``) debe tener una comunicación extra con el *low level
 allocator* para poder obtener todas las celdas de memoria que existen en el
 *heap*.
 
 A diferencia del conteo de referencias, este algoritmo es :ref:`indirecto
-<ref_gc_direct>` y :ref:`no incremental <ref_gc_inc>`, ya que se realiza un
+<gc_direct>` y :ref:`no incremental <gc_inc>`, ya que se realiza un
 recorrido de todo el *heap* de forma espaciada a través de la ejecución del
 programa. En general el *mutator* sufre pausas considerablemente mayores (en
 promedio) que con el conteo de referencias, lo que puede ser problemático para
 aplicaciones con requerimientos rígidos de tiempo, como aplicaciones
 *real-time*. Debido a la percepción de las pausas grandes, este tipo de
 recorrido de todo el *heap* de forma espaciada a través de la ejecución del
 programa. En general el *mutator* sufre pausas considerablemente mayores (en
 promedio) que con el conteo de referencias, lo que puede ser problemático para
 aplicaciones con requerimientos rígidos de tiempo, como aplicaciones
 *real-time*. Debido a la percepción de las pausas grandes, este tipo de
-colectores se conocen como :ref:`stop-the-world <ref_gc_concurrent>` (o
+colectores se conocen como :ref:`stop-the-world <gc_concurrent>` (o
 *detener el mundo*).
 
 Una ventaja fundamental sobre el conteo de referencias es la posibilidad de
 *detener el mundo*).
 
 Una ventaja fundamental sobre el conteo de referencias es la posibilidad de
@@ -1679,7 +1679,7 @@ linealmente.
 
 
 
 
 
 
-.. _ref_gc_copy:
+.. _gc_copy:
 
 Copia de semi-espacio
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Copia de semi-espacio
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -1727,7 +1727,7 @@ cambia al ser movidas, es necesario actualizar la dirección de memoria de
 todas las celdas *vivas*. Para esto se almacena una dirección de memoria de
 redirección, *forwarding address*, en las celdas que mueven. La *forwarding
 address* sirve a su vez de marca, para no recorrer una celda dos veces (como
 todas las celdas *vivas*. Para esto se almacena una dirección de memoria de
 redirección, *forwarding address*, en las celdas que mueven. La *forwarding
 address* sirve a su vez de marca, para no recorrer una celda dos veces (como
-se explica en :ref:`ref_gc_intro_mark`). Cuando se encuentra una celda que ya
+se explica en :ref:`gc_intro_mark`). Cuando se encuentra una celda que ya
 fue movida, simplemente se actualiza la referencia por la cual se llegó a esa
 celda para que apunte a la nueva dirección, almacenada en la *forwarding
 address*. Una vez finalizado este proceso, el *Fromspace* y *Tospace*
 fue movida, simplemente se actualiza la referencia por la cual se llegó a esa
 celda para que apunte a la nueva dirección, almacenada en la *forwarding
 address*. Una vez finalizado este proceso, el *Fromspace* y *Tospace*
@@ -1789,11 +1789,11 @@ Esta técnica tiene nombres variados en inglés: *semi-space*, *two-space*
 o simplemente *copying collector*. En este documento se denomina "copia de
 semi-espacio" porque los otros nombres son demasiado generales y pueden
 describir, por ejemplo, algoritmos donde no hay copia de celdas o donde no hay
 o simplemente *copying collector*. En este documento se denomina "copia de
 semi-espacio" porque los otros nombres son demasiado generales y pueden
 describir, por ejemplo, algoritmos donde no hay copia de celdas o donde no hay
-2 semi-espacios (como se verá en :ref:`ref_gc_art`).
+2 semi-espacios (como se verá en :ref:`gc_art`).
 
 
-Al igual que el :ref:`ref_gc_mark_sweep` este algoritmo es :ref:`indirecto
-<ref_gc_direct>`, :ref:`no incremental <ref_gc_inc>` y :ref:`stop-the-world
-<ref_gc_concurrent>`. Las diferencias con los esquemas vistos hasta ahora son
+Al igual que el :ref:`gc_mark_sweep` este algoritmo es :ref:`indirecto
+<gc_direct>`, :ref:`no incremental <gc_inc>` y :ref:`stop-the-world
+<gc_concurrent>`. Las diferencias con los esquemas vistos hasta ahora son
 evidentes. La principal ventaja sobre el marcado y barrido (que requiere una
 pasada sobre el *live set*, el marcado, y otra sobre el *heap* entero, el
 barrido) es que este método require una sola pasada y sobre las celdas vivas
 evidentes. La principal ventaja sobre el marcado y barrido (que requiere una
 pasada sobre el *live set*, el marcado, y otra sobre el *heap* entero, el
 barrido) es que este método require una sola pasada y sobre las celdas vivas
@@ -2050,7 +2050,7 @@ nueva ubicación de ``h3``, como se muestra en la figura
 
 
 
 
 
 
-.. _ref_gc_art:
+.. _gc_art:
 
 Estado del arte
 ----------------------------------------------------------------------------
 
 Estado del arte
 ----------------------------------------------------------------------------
@@ -2093,7 +2093,7 @@ clase en particular).
 
 
 
 
 
 
-.. _ref_gc_direct:
+.. _gc_direct:
 
 Recolección directa / indirecta
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Recolección directa / indirecta
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -2103,15 +2103,15 @@ compilador o lenguaje instrumenta al *mutator* de forma tal que la información
 sobre el grafo de conectividad se mantenga activamente cada vez que hay un
 cambio en él. Normalmente se utiliza un contador de referencia en cada celda
 para este propósito, permitiendo almacenar en todo momento la cantidad de
 sobre el grafo de conectividad se mantenga activamente cada vez que hay un
 cambio en él. Normalmente se utiliza un contador de referencia en cada celda
 para este propósito, permitiendo almacenar en todo momento la cantidad de
-nodos que apuntan a ésta (ver :ref:`ref_gc_rc`). Esto permite reclamar una
+nodos que apuntan a ésta (ver :ref:`gc_rc`). Esto permite reclamar una
 celda instantáneamente cuando el *mutator* deja de hacer referencia a ella.
 Este tipo de recolectores son inherentemente :ref:`incrementales
 celda instantáneamente cuando el *mutator* deja de hacer referencia a ella.
 Este tipo de recolectores son inherentemente :ref:`incrementales
-<ref_gc_inc>`.
+<gc_inc>`.
 
 Por el contrario, los recolectores **indirectos** normalmente no
 interfieren con el *mutator* en cada actualización del grafo de
 conectividad (exceptuando algunos :ref:`recolectores incrementales
 
 Por el contrario, los recolectores **indirectos** normalmente no
 interfieren con el *mutator* en cada actualización del grafo de
 conectividad (exceptuando algunos :ref:`recolectores incrementales
-<ref_gc_inc>` que a veces necesitan instrumentar el *mutator* pero no para
+<gc_inc>` que a veces necesitan instrumentar el *mutator* pero no para
 mantener el estado del grafo de conectividad completo). La recolección se
 dispara usualmente cuando el *mutator* requiere alocar memoria pero no hay
 más memoria libre conocida disponible y el recolector se encarga de generar
 mantener el estado del grafo de conectividad completo). La recolección se
 dispara usualmente cuando el *mutator* requiere alocar memoria pero no hay
 más memoria libre conocida disponible y el recolector se encarga de generar
@@ -2119,11 +2119,11 @@ la información de conectividad desde cero para determinar qué celdas son
 *basura*.
 
 Esta es la madre de toda clasificación, también conocidos como :ref:`conteo de
 *basura*.
 
 Esta es la madre de toda clasificación, también conocidos como :ref:`conteo de
-referencias <ref_gc_rc>` (directa) y *traicing garbage collection*
+referencias <gc_rc>` (directa) y *traicing garbage collection*
 (indirecta). Prácticamente todos los recolectores menos el :ref:`conteo de
 (indirecta). Prácticamente todos los recolectores menos el :ref:`conteo de
-referencias <ref_gc_rc>` están dentro de esta última categoría (como por
-ejemplo, el :ref:`marcado y barrido <ref_gc_mark_sweep>` y :ref:`copia de
-semi-espacio <ref_gc_copy>`).
+referencias <gc_rc>` están dentro de esta última categoría (como por
+ejemplo, el :ref:`marcado y barrido <gc_mark_sweep>` y :ref:`copia de
+semi-espacio <gc_copy>`).
 
 Otros ejemplos de recolectores modernos *directos* son el recolector de
 basura de Python_ [NAS00]_ y [LINS05]_ (aunque ambos tiene un algoritmo
 
 Otros ejemplos de recolectores modernos *directos* son el recolector de
 basura de Python_ [NAS00]_ y [LINS05]_ (aunque ambos tiene un algoritmo
@@ -2131,7 +2131,7 @@ basura de Python_ [NAS00]_ y [LINS05]_ (aunque ambos tiene un algoritmo
 
 
 
 
 
 
-.. _ref_gc_inc:
+.. _gc_inc:
 
 Recolección incremental
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Recolección incremental
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -2142,7 +2142,7 @@ causadas por el recolector (aunque generalmente el resultado es un mayor
 costo total de recolección en términos de tiempo).
 
 De los `algoritmos clásicos`_ el único que es incremental en su forma más
 costo total de recolección en términos de tiempo).
 
 De los `algoritmos clásicos`_ el único que es incremental en su forma más
-básica es el :ref:`conteo de referencias <ref_gc_rc>`. Otros recolectores
+básica es el :ref:`conteo de referencias <gc_rc>`. Otros recolectores
 pueden hacerse incrementales de diversas maneras, pero en general consta de
 hacer parte del trabajo de escanear el grafo de conectividad cada vez que el
 *mutator* aloca memoria. En general para hacer esto es también necesario
 pueden hacerse incrementales de diversas maneras, pero en general consta de
 hacer parte del trabajo de escanear el grafo de conectividad cada vez que el
 *mutator* aloca memoria. En general para hacer esto es también necesario
@@ -2150,8 +2150,8 @@ instrumentar al *mutator* de forma tal que informe al recolector cada vez que
 cambia el grafo de conectividad, para que éste pueda marcar al sub-grafo
 afectado por el cambio como *desactualizado* y así re-escanearlo nuevamente en
 la próxima iteración. Para realizar esto en recolectores :ref:`indirectos
 cambia el grafo de conectividad, para que éste pueda marcar al sub-grafo
 afectado por el cambio como *desactualizado* y así re-escanearlo nuevamente en
 la próxima iteración. Para realizar esto en recolectores :ref:`indirectos
-<ref_gc_direct>` se utiliza la :ref:`abstracción tricolor
-<ref_gc_intro_tricolor>`; cuando el *mutator* cambia una referencia, se marca
+<gc_direct>` se utiliza la :ref:`abstracción tricolor
+<gc_intro_tricolor>`; cuando el *mutator* cambia una referencia, se marca
 *gris* la celda que la contiene, de modo que el recolector vuelva a visitarla.
 
 En general la eficiencia de los recolectores incrementales disminuye
 *gris* la celda que la contiene, de modo que el recolector vuelva a visitarla.
 
 En general la eficiencia de los recolectores incrementales disminuye
@@ -2166,7 +2166,7 @@ Ejemplos de recolectores que se encuentran dentro de esta categoría son
 
 
 
 
 
 
-.. _ref_gc_concurrent:
+.. _gc_concurrent:
 
 Recolección concurrente / paralela / *stop-the-world*
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Recolección concurrente / paralela / *stop-the-world*
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -2242,7 +2242,7 @@ los hilos disponibles para realizar la recolección (ver figura
 
 Para lograr que un recolector sea concurrente generalmente el mecanismo es
 similar al necesario para hacer un :ref:`recolector incremental
 
 Para lograr que un recolector sea concurrente generalmente el mecanismo es
 similar al necesario para hacer un :ref:`recolector incremental
-<ref_gc_inc>`: hay que instrumentar al *mutator* para que informe al
+<gc_inc>`: hay que instrumentar al *mutator* para que informe al
 recolector cuando se realiza algún cambio en el grafo de conectividad, de
 forma tal que pueda volver a escanear el sub-grafo afectado por el cambio.
 
 recolector cuando se realiza algún cambio en el grafo de conectividad, de
 forma tal que pueda volver a escanear el sub-grafo afectado por el cambio.
 
@@ -2267,12 +2267,12 @@ ofrece paralelización del procesamiento del recolector en varios hilos) son
    o más núcleos (*cores*) independientes que trabajan a la misma frecuencia,
    pero dentro de un solo circuito integrado o procesador.
 
    o más núcleos (*cores*) independientes que trabajan a la misma frecuencia,
    pero dentro de un solo circuito integrado o procesador.
 
-Todos los :ref:`algoritmos clásicos <ref_gc_classic>` que se han citado son
+Todos los :ref:`algoritmos clásicos <gc_classic>` que se han citado son
 del tipo *stop-the-world*.
 
 
 
 del tipo *stop-the-world*.
 
 
 
-.. _ref_gc_free_list:
+.. _gc_free_list:
 
 Lista de libres / *pointer bump allocation*
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Lista de libres / *pointer bump allocation*
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -2285,7 +2285,7 @@ completamente.
 
 En términos generales, hay dos formas fundamentales de organizar el *heap*,
 manteniendo una lista de libres o realizando *pointer bump allocation*, como
 
 En términos generales, hay dos formas fundamentales de organizar el *heap*,
 manteniendo una lista de libres o realizando *pointer bump allocation*, como
-se explicó en :ref:`ref_gc_copy`. La primera forma consiste, a grandes rasgos,
+se explicó en :ref:`gc_copy`. La primera forma consiste, a grandes rasgos,
 en separar el *heap* en celdas (que pueden agruparse según tamaño)
 y enlazarlas en una lista de libres. Al solicitarse una nueva celda
 simplemente se la desenlaza de la lista de libres. Por otro lado, cuando el
 en separar el *heap* en celdas (que pueden agruparse según tamaño)
 y enlazarlas en una lista de libres. Al solicitarse una nueva celda
 simplemente se la desenlaza de la lista de libres. Por otro lado, cuando el
@@ -2293,15 +2293,15 @@ recolector detecta una celda *muerta*, la vuelve a enlazar en la lista de
 libres. Este es un esquema simple pero con limitaciones, entre las
 principales, el costo de alocar puede ser alto si hay muchos tamaños distintos
 de celda y soportar tamaño de celda variable puede ser complejo o acarrear
 libres. Este es un esquema simple pero con limitaciones, entre las
 principales, el costo de alocar puede ser alto si hay muchos tamaños distintos
 de celda y soportar tamaño de celda variable puede ser complejo o acarrear
-muchas otras ineficiencias. :ref:`ref_gc_mark_sweep` en general usa este
-esquema, al igual que :ref:`ref_gc_rc`.
+muchas otras ineficiencias. :ref:`gc_mark_sweep` en general usa este
+esquema, al igual que :ref:`gc_rc`.
 
 Otro forma de organizar el *heap* es utilizándolo como una especie de *stack*
 en el cual para alocar simplemente se incrementa un puntero. Este esquema es
 simple y eficiente, si el recolector puede mover celdas (ver
 
 Otro forma de organizar el *heap* es utilizándolo como una especie de *stack*
 en el cual para alocar simplemente se incrementa un puntero. Este esquema es
 simple y eficiente, si el recolector puede mover celdas (ver
-:ref:`ref_gc_moving`); de otra manera alocar puede ser muy costoso si hay que
+:ref:`gc_moving`); de otra manera alocar puede ser muy costoso si hay que
 buscar un *hueco* en el heap (es decir, deja de reducirse a incrementar un
 buscar un *hueco* en el heap (es decir, deja de reducirse a incrementar un
-puntero). El clásico ejemplo de esta familia es :ref:`ref_gc_copy`.
+puntero). El clásico ejemplo de esta familia es :ref:`gc_copy`.
 
 Sin embargo, entre estos dos extremos, hay todo tipo de híbridos. Existen
 recolectores basados en *regiones*, que se encuentran en un punto intermedio.
 
 Sin embargo, entre estos dos extremos, hay todo tipo de híbridos. Existen
 recolectores basados en *regiones*, que se encuentran en un punto intermedio.
@@ -2311,25 +2311,25 @@ las regiones en sí se administran como una lista de libres (como por ejemplo
 allocators* que alocan páginas completas (similar a las regiones) y dentro de
 cada página se alocan las celdas. Ambas, páginas y celdas, se administran como
 listas de libres (ejemplos que utilizan este esquema son [BOEHWD]_ y el
 allocators* que alocan páginas completas (similar a las regiones) y dentro de
 cada página se alocan las celdas. Ambas, páginas y celdas, se administran como
 listas de libres (ejemplos que utilizan este esquema son [BOEHWD]_ y el
-:ref:`recolector actual de D <ref_dgc_actual>`).
+:ref:`recolector actual de D <dgc_actual>`).
 
 
 
 
 
 
-.. _ref_gc_moving:
+.. _gc_moving:
 
 Movimiento de celdas
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Otra característica muy importante del recolector de basura es si mueve las
 celdas o no. En general el movimiento de celdas viene de la mano del esquema
 
 Movimiento de celdas
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Otra característica muy importante del recolector de basura es si mueve las
 celdas o no. En general el movimiento de celdas viene de la mano del esquema
-de :ref:`pointer bump allocation <ref_gc_free_list>`, ya que *compacta* todas
+de :ref:`pointer bump allocation <gc_free_list>`, ya que *compacta* todas
 las celdas *vivas* al comienzo del *heap* luego de una recolección,
 permitiendo este esquema para alocar nuevas celdas, pero puede utilizarse en
 esquemas híbridos como recolectores basados en *regiones* (por ejemplo
 [BLAC08]_).
 
 Además los recolectores con movimiento de celdas deben ser :ref:`precisos
 las celdas *vivas* al comienzo del *heap* luego de una recolección,
 permitiendo este esquema para alocar nuevas celdas, pero puede utilizarse en
 esquemas híbridos como recolectores basados en *regiones* (por ejemplo
 [BLAC08]_).
 
 Además los recolectores con movimiento de celdas deben ser :ref:`precisos
-<ref_gc_conserv>`, porque es necesario tener la información completa de los
+<gc_conserv>`, porque es necesario tener la información completa de los
 tipos para saber cuando actualizar los punteros (de otra manera se podría
 escribir un dato de una celda que no era un puntero). Para que un recolector
 pueda mover celdas, aunque sea parcialmente, en recolectores *semi-precisos*
 tipos para saber cuando actualizar los punteros (de otra manera se podría
 escribir un dato de una celda que no era un puntero). Para que un recolector
 pueda mover celdas, aunque sea parcialmente, en recolectores *semi-precisos*
@@ -2339,16 +2339,16 @@ referencia no-precisa a ella, y por lo tanto no puede ser movida (porque no se
 puede estar seguro si es posible actualizar dicha referencia).
 
 La ventaja principal de los colectores con movimiento es la posibilidad de
 puede estar seguro si es posible actualizar dicha referencia).
 
 La ventaja principal de los colectores con movimiento es la posibilidad de
-utilizar :ref:`pointer bump allocation <ref_gc_free_list>` y que es sencillo
-implementar recolectores :ref:`generacionales <ref_gc_part>` sobre estos.
+utilizar :ref:`pointer bump allocation <gc_free_list>` y que es sencillo
+implementar recolectores :ref:`generacionales <gc_part>` sobre estos.
 
 
-De los algoritmos clásicos sólo la :ref:`copia de semi-espacios <ref_gc_copy>`
-mueve celdas, el :ref:`conteo de referencias <ref_gc_rc>` y :ref:`marcado
-y barrido <ref_gc_mark_sweep>` no lo hacen. Además hay otro algoritmo bastante
+De los algoritmos clásicos sólo la :ref:`copia de semi-espacios <gc_copy>`
+mueve celdas, el :ref:`conteo de referencias <gc_rc>` y :ref:`marcado
+y barrido <gc_mark_sweep>` no lo hacen. Además hay otro algoritmo bastante
 básico que mueve celdas, el **marcado y compactado**. Éste no tiene
 2 semi-espacios, directamente mueve las celdas compactándolas al comienzo del
 *heap*. El algoritmo es un poco más complejo que la :ref:`copia de
 básico que mueve celdas, el **marcado y compactado**. Éste no tiene
 2 semi-espacios, directamente mueve las celdas compactándolas al comienzo del
 *heap*. El algoritmo es un poco más complejo que la :ref:`copia de
-semi-espacios <ref_gc_copy>` pero suele poder proveer una mayor localidad de
+semi-espacios <gc_copy>` pero suele poder proveer una mayor localidad de
 referencia y *desperdicia* un semi-espacio que está inutilizado salgo en el
 momento de la recolección. Por ejemplo para Mono_, que antes usaba un
 recolector conservativo sin movimiento ([BOEHWD]_) se está implementando un
 referencia y *desperdicia* un semi-espacio que está inutilizado salgo en el
 momento de la recolección. Por ejemplo para Mono_, que antes usaba un
 recolector conservativo sin movimiento ([BOEHWD]_) se está implementando un
@@ -2356,7 +2356,7 @@ recolector de este tipo [MOLAWE]_ [MOLA06]_.
 
 
 
 
 
 
-.. _ref_gc_conserv:
+.. _gc_conserv:
 
 Recolectores conservativos vs precisos
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Recolectores conservativos vs precisos
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -2369,7 +2369,7 @@ o no. Esto trae una variada cantidad de problemas, como retención de celdas
 que en realidad son *basura* simplemente porque hay algún dato que coincide
 con la dirección de memoria en la que está almacenada esa celda *basura*
 [#gcflasepos]_. Además los recolectores puramente conservativos no puede mover
 que en realidad son *basura* simplemente porque hay algún dato que coincide
 con la dirección de memoria en la que está almacenada esa celda *basura*
 [#gcflasepos]_. Además los recolectores puramente conservativos no puede mover
-celdas (ver :ref:`ref_gc_moving`), porque no pueden arriesgarse a actualizar
+celdas (ver :ref:`gc_moving`), porque no pueden arriesgarse a actualizar
 los punteros por el riesgo que existe de que sean falsos positivos.
 
 .. [#gcflasepos] Esto es lo que se conoce como un *falso positivo*, algo que
 los punteros por el riesgo que existe de que sean falsos positivos.
 
 .. [#gcflasepos] Esto es lo que se conoce como un *falso positivo*, algo que
@@ -2395,19 +2395,19 @@ de forma conservativa y otras de forma precisa, de manera de mitigar, aunque
 sea de forma parcial, los efectos adversos de los recolectores conservativos.
 Estos recolectores son conocidos como *semi-precisos*. Los recolectores
 semi-precisos pueden mover celdas si utilizan un mecanismo de *pinning* (ver
 sea de forma parcial, los efectos adversos de los recolectores conservativos.
 Estos recolectores son conocidos como *semi-precisos*. Los recolectores
 semi-precisos pueden mover celdas si utilizan un mecanismo de *pinning* (ver
-:ref:`ref_gc_moving`).
+:ref:`gc_moving`).
 
 El ejemplo de recolector conservativo por excelencia es el recolector
 `Boehm-Demers-Wiser`_ ([BOEH88]_, [BOEH91]_, [BOEH93]_, [BOEHWD]_) aunque
 puede comportarse de forma semi-precisa si el usuario se encarga de darle la
 información de tipos (en cuyo caso el recolector deja de ser transparente para
 el usuario). Otros ejemplos de recolectores con cierto grado de
 
 El ejemplo de recolector conservativo por excelencia es el recolector
 `Boehm-Demers-Wiser`_ ([BOEH88]_, [BOEH91]_, [BOEH93]_, [BOEHWD]_) aunque
 puede comportarse de forma semi-precisa si el usuario se encarga de darle la
 información de tipos (en cuyo caso el recolector deja de ser transparente para
 el usuario). Otros ejemplos de recolectores con cierto grado de
-conservativismo son el :ref:`recolector actual de D <ref_dgc_actual>`
+conservativismo son el :ref:`recolector actual de D <dgc_actual>`
 y [BLAC08]_.
 
 
 
 y [BLAC08]_.
 
 
 
-.. _ref_gc_part:
+.. _gc_part:
 
 Recolección particionada
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Recolección particionada
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
index 4f1282448b51836798ea16acc40c9bf14fbc8f1c..a8fb1ca8aca5edc8b0876abf5f4b3a81e59a1fd5 100644 (file)
@@ -4,7 +4,7 @@
    ESTADO: TERMINADO
 
 
    ESTADO: TERMINADO
 
 
-.. _ref_intro:
+.. _intro:
 
 Introducción
 ============================================================================
 
 Introducción
 ============================================================================
@@ -108,21 +108,21 @@ Organización
 Este trabajo se encuentra dividido en 7 cápitos que se describen
 a continuación:
 
 Este trabajo se encuentra dividido en 7 cápitos que se describen
 a continuación:
 
-1. :ref:`ref_intro`: breve descripción del problema a tratar, presentando
+1. :ref:`intro`: breve descripción del problema a tratar, presentando
    los objetivos y alcances del trabajo.
    los objetivos y alcances del trabajo.
-2. :ref:`ref_d`: presenta las características principales del lenguaje,
+2. :ref:`d_lang`: presenta las características principales del lenguaje,
    destacando aquellas de mayor relevancia para este trabajo.
    destacando aquellas de mayor relevancia para este trabajo.
-3. :ref:`ref_gc`: presenta los algoritmos básicos de recolección de basura
+3. :ref:`gc`: presenta los algoritmos básicos de recolección de basura
    y describe el estado del arte.
    y describe el estado del arte.
-4. :ref:`ref_dgc`: explica los problemas particulares que presenta el
+4. :ref:`dgc`: explica los problemas particulares que presenta el
    lenguaje para la recolección de basura, describe el diseño
    e implementación del recolector actual y presenta sus principales
    deficiencias.
    lenguaje para la recolección de basura, describe el diseño
    e implementación del recolector actual y presenta sus principales
    deficiencias.
-5. :ref:`ref_analisis`: realiza un recorrido por los algoritmos presentados
-   en :ref:`ref_gc` analizando su viabilidad para aplicarse en D_.
-6. :ref:`ref_solucion`: propone una solución a los problemas encontrados en
-   :ref:`ref_dgc` en base al análisis hecho en :ref:`ref_analisis`.
-7. :ref:`ref_conclusion`: describe los resultados del trabajo, proponiendo
+5. :ref:`analisis`: realiza un recorrido por los algoritmos presentados
+   en :ref:`gc` analizando su viabilidad para aplicarse en D_.
+6. :ref:`solucion`: propone una solución a los problemas encontrados en
+   :ref:`dgc` en base al análisis hecho en :ref:`analisis`.
+7. :ref:`conclusion`: describe los resultados del trabajo, proponiendo
    trabajos futuros y relacionados.
 
 
    trabajos futuros y relacionados.
 
 
index 8836d3ada6bbd0d235f25a82b8db5ef2b1488f13..6eeac585f32ddd11a3b449753109cfa091a11c38 100644 (file)
@@ -3,7 +3,7 @@
 .. target-notes::
 
 
 .. target-notes::
 
 
-.. _ref_refs:
+.. _refs:
 
 .. [BKIP08] Kris Macleod Bell, Lars Ivar Igesund, Sean Kelly, and Michael
    Parker. Learn to Tango with D. Apress, 2007. ISBN 1-59059-960-8.
 
 .. [BKIP08] Kris Macleod Bell, Lars Ivar Igesund, Sean Kelly, and Michael
    Parker. Learn to Tango with D. Apress, 2007. ISBN 1-59059-960-8.
index 4e4fa947bb126eeb453c95386b68dca80c31396c..67630a8aa7d401cc88677ec9c4631b74edd3f97e 100644 (file)
@@ -3,7 +3,7 @@
    ESTADO: TERMINADO
 
 
    ESTADO: TERMINADO
 
 
-.. _ref_resumen:
+.. _resumen:
 
 Resumen
 ============================================================================
 
 Resumen
 ============================================================================
index b4bbf4e1cc2296cc7f335727a169902774b50fbd..37062cb7d3c714d83bcdef54e5d27b88ebd02c84 100644 (file)
@@ -3,7 +3,7 @@
    ESTADO: SIN EMPEZAR
 
 
    ESTADO: SIN EMPEZAR
 
 
-.. _ref_solucion:
+.. _solucion:
 
 Solución adoptada
 ============================================================================
 
 Solución adoptada
 ============================================================================
index aa19f4fc100f5b45c4d700d54da442c8d282b0c2..a829fd54779cb7e7bc11133123452bb129b8e80d 100644 (file)
@@ -5,7 +5,7 @@
    ESTADO: SIN EMPEZAR
 
 
    ESTADO: SIN EMPEZAR
 
 
-.. _ref_analisis:
+.. _analisis:
 
 Análisis de viabilidad
 ============================================================================
 
 Análisis de viabilidad
 ============================================================================