Corregir Limitaciones en la Introducción

[z.facultad/75.00/informe.git] / informe.rst

==========================
Recolección de basura en D
==========================


-----
Tesis
-----

:Autor: Leandro Lucarella (77891)
:Contacto: llucare@fi.uba.ar
:Autor: Tutora: Lic. Rosa Wachenchauzer
:Organización: Departamento de Computación, Facultad de Ingeniería
:Organización: Universidad de Buenos Aires
:Fecha: |date|
:Revisión: 1
:Estado: Borrador


.. contents::


.. ===========================================================================


Introducción
============
.. Presenta el problema y temas a ser tratados en el trabajo.
   ESTADO: TERMINADO

Los lenguajes de programación modernos tienen una tendencia cada vez
más marcada a adoptar técnicas sofisticadas, haciéndolos más ricos y
convirtiéndolos realmente en lenguajes, no en meros preprocesadores que
convierten de una forma muy directa el código en *assembly*, permitiendo
construcciones semánticamente más ricas y permitiendo al programar una
mayor expresividad para plasmar algoritmos sin detenerse en los detalles
del *hardware*.

Estos conceptos supuestamente avanzados provienen, en general, de
lenguajes académicos (muchos de ellos funcionales) que implementan estas
funcionalidades hace mucho tiempo, pero que para su época, o bien no
tuvieron suficiente difusión en el ambiente comercial, o bien eran muy
lentos por la baja capacidad de procesamiento de la época o incluso
demasiado *revolucionarios* para ser adoptados por programadores que no
podían ver las ventajas que esos nuevos conceptos proveen.

El caso de la recolección de basura (*garbage collection* en inglés)
es uno de los más representativos. Lisp_ introdujo a principio de los
'60 este concepto, como un mecanismo para alocar
y liberar recursos de forma automática. Pero no fue hasta avanzados los
'90 que esta técnica se empezó a utilizar en lenguajes de programación
de uso comercial, cuando fue popularizado por Java_. Incluso luego de
más de 30 años para Java_ era costosa la recolección de basura, lo que
sumado a la presencia de una máquina virtual para ejecutar los programas
producidos, condujo a que estos lenguajes sean notablemente lentos. Aún
así Java_ creció y entre las mejoras introducidas hubieron mejoras en
la recolección de basura. Otros lenguaje de programación populares que
utilizan alguna forma de recolección de basura son Python_, Ruby_, PHP_
y `C#`_, entre otros.

.. _Lisp: http://www.lisp.org/
.. _Java: http://www.java.com/
.. _Python: http://www.python.org/
.. _Ruby: http://www.ruby-lang.org/
.. _PHP: http://www.php.net/
.. _`C#`: http://www.ecma-international.org/publications/standards/Ecma-334.htm

.. INTRODUCCION ..............................................................

Importancia de la Recolección de Basura
---------------------------------------
.. Breve descripción de la utilidad de la recolección de basura
   ESTADO: TERMINADO

La recolección de basura es muchas veces vista por sus críticos de
una forma bastante *naive*. Muchas veces se argumenta que sólo es
útil para programadores descuidados o que su necesidad es sólo una
manifestación de un mal diseño. Si bien estas dos afirmaciones pueden
ser, en algunos casos, ciertas, es falaz pensar que ese es la única
ventaja de un recolector de basura. Uno de los aspectos más importantes
de un recolector de basura es lograr un mayor nivel de abstracción
[JOLI96]_. En particular, al diseñar o programar bibliotecas, de no
haber un recolector de basura, **la administración de memoria pasa a ser
parte de la interfaz de la biblioteca**. Y lo peor de este aspecto es
que muy pocas veces esto es tenido en cuenta, derivando en bibliotecas
muy difíciles de usar correctamente sin perder memoria, por no quedar
bien clara la responsabilidad del manejo de memoria.

Esto se debe a que, como se mencionó anteriormente, el manejo de memoria
es un *artefacto* proveniente del *hardware*, no un concepto propio
de los algoritmos a representar y como tal, nos impide desarrollar una
mayor abstracción.

Muchas veces se aduce también que la recolección de basura impide
el desarrollo de programas eficientes. Si bien es innegable que la
recolección de basura impone una carga extra, ésta es, en la mayoría
de los casos, imperceptible. Incluso algunos algoritmos de recolección
de basura pueden aumentar la eficiencia en casos determinados, como los
recolectores que compactan, que pueden minimizar considerablemente la
cantidad de páginas de memoria referenciadas por el programa, mejorando
el *hit-ratio* tanto de la memoria virtual como del *cache*.  Aún si
este no fuera el caso, o en casos de sistemas de tiempo real o zonas muy
críticas en cuanto a la eficiencia, muchas veces es posible suspender
el recolector de basura en dicho fragmento de código. Es cierto que esto
rompe un poco con la idea de ganar abstracción, pero es necesario sólo
en casos donde hay que realizar optimizaciones y las optimizaciones son,
en general, dependientes de la plataforma (*hardware*) y por lo tanto
de difícil abstracción.

El recolector de basura debe tener un comportamiento correcto y predecible
para que sea útil, si el programador no puede confiar en el recolector
de basura, éste se vuelve más un problema que una solución, porque
introduce nuevos puntos de falla en los programas, y lo que es peor,
puntos de falla no controlados por el programador, volviendo mucho más
difícil la búsqueda de errores.

.. INTRODUCCION ..............................................................

El Lenguaje de Programación D
-----------------------------
.. Breve descripción del lenguaje de programación D
   ESTADO: TERMINADO

D_ es un lenguaje de programación joven. Nació en 1999 y el 2 de enero
de 2007 salió su `versión 1.0`_. Poco tiempo después se continúo el
desarrollo del lenguaje en la `versión 2.0`_, aún inestable y en la
cual se está experimentando principalmente sobre *const-correctness*
(ya sea como una forma de programación por contratos como para mejorar
las oportunidades de optimización del compilador, en especial con
código multi-hilo), reflexión y características para soportar mejor
programación funcional (como *clausuras* completas) y programación
genérica.

Su creador, `Walter Bright`_, desarrollador principal de Zortech C++,
uno de los primeros compilador de C++ que compilaba a código nativo,
dice bien claro como nace el lenguaje, citando en su sitio web:

  It seems to me that most of the "new" programming languages fall
  into one of two categories: Those from academia with radical new
  paradigms and those from large corporations with a focus on RAD and
  the web. Maybe it's time for a new language born out of practical
  experience implementing compilers.

.. _D: http://www.digitalmars.com/d/
.. _`versión 1.0`: http://www.digitalmars.com/d/1.0/changelog.html
.. _`versión 2.0`: http://www.digitalmars.com/d/changelog.html
.. _`Walter Bright`: http://www.walterbright.com/

Lo que podría traducirse como:

  Parece que la mayoría de los lenguajes de programación "nuevos" caen
  en 2 categorías: aquellos académicos con nuevos paradigmas radicales y
  aquellos de grandes corporaciones con el foco en el desarrollo rápido
  y web. Tal vez es hora de que nazca un nuevo lenguaje de la experiencia
  práctica implementando compiladores.

D_ es un lenguaje de programación con sintaxis tipo C, multiparadigma,
compilado, con tipado fuerte y estático, con buenas capacidades tanto de
programación de bajo nivel (*system programming*) como de alto nivel,
siendo incluso compatible binariamente con C (se puede enlazar código
objeto C con código objeto D). Y este es tal vez el punto más fuerte
de D_, brindar lo mejor de los 2 mundos. Si bien tiene herramientas
de muy bajo nivel, que por lo tanto son muy propensas a errores, da
una infinidad de mecanismos para evitar el uso de estas herramientas
a menos que sea realmente necesario.  Además pone mucho énfasis en
la programación confiable, para lo cual provee muchos mecanismos para
detectar errores en los programas de forma temprana.

Si puede pensarse en C++ como un "C mejor", podría decirse que D_ es
un "C++ mejor", ya que el objetivo del lenguaje es muy similar a C++,
pero implementa muchas características que jamás pudieron entrar en
el estándar de C++ y lo hace de una forma mucho más limpia, ya que
no debe lidiar con problemas de compatibilidad hacia atrás, y cuenta
con la experiencia del camino recorrido por C++, pudiendo extraer de
él los mejores conceptos pero evitando sus mayores problemas también.

Una de las características que nunca pudo entrar en el estándar de C++
es la recolección de basura. D_ no comete el mismo error.

.. INTRODUCCION ..............................................................

Objetivo
--------
.. Objetivo de la tesis
   ESTADO: TERMINADO, EN REVISION

La recolección de basura en D_ es un problema prácticamente nuevo. Si bien
pueden considerarse válidos todos los modelos propuestos para recolección
de basura en C, estos son muy restrictivos y poco eficientes, por lo
promiscuo que este lenguaje. Por otro lado D_ provee muchas construcciones
de alto nivel, lo que hace que la necesidad de utilizar construcciones de
bajo nivel sea muy escasa, por lo tanto brinda un campo importante a
explorar en cuanto a mejoras para el recolector de basura.

Por lo tanto el objetivo del presente trabajo puede resumirse en los
siguientes puntos:

- Investigar y analizar la viabilidad de mejoras al recolector de
  basura de D_, tanto mejoras menores dentro de las limitaciones actuales
  del lenguaje (incluyendo pero no limitado a mejoras en el algoritmo
  actual de recolección y soluciones en *espacio de usuario* -como
  biblioteca-), como proponiendo mejoras al lenguaje que permitan la
  implementación recolectores más precisos y eficientes.
- Elegir un conjunto de las mejores soluciones halladas e implementarlas.
  Las soluciones que necesiten modificaciones en el lenguaje serán
  implementadas modificando el compilador libre de D_ GDC_, que
  también será utilizado como plataforma principal de desarrollo y
  prueba (debido a la disponibilidad completa del código fuente y
  la libertad de usarlo y modificarlo libremente). De todas formas,
  siempre se priorizarán las modificaciones al *frontend* [#frontend]_
  sobre las modificaciones al *backend*, permitiendo así que las mejoras
  puedan ser probadas eventualmente en otros compiladores que utilicen
  el *frontend* publicado por DigitalMars_, como DMD_.
- Realizar pruebas sobre aplicaciones lo más variadas y reales posible
  sobre todas las soluciones implementadas, de manera de determinar de
  forma fehaciente las ventajas de unas y otras en cuanto a latencia,
  consumo de memoria, consumo de procesador, tiempos de pausa, etc.
- Presentar las conclusiones obtenidas del análisis y las pruebas
  realizadas, tanto en el ámbito académico de la facultad como a la
  comunidad de D_ (con el objetivo de sumar lo construido en este trabajo
  al lenguaje).

.. [#frontend] El *frontend* es el módulo del compilador que realiza el
   análisis sintáctico y semántico del lenguaje. GDC_ utiliza como
   *frontend* el que provee libremente DigitalMars_.
.. [#backend] El *backend* es el módulo del compilador que emite
   el código binario (o *assembly*, o el lenguaje que produzca el
   compilador como resultado final). GDC utiliza el *backend* del GCC_
   (*GNU Compiler Collection*), uno de los compiladores más populares.


.. INTRODUCCION ..............................................................

Limitaciones
------------
.. Cosas que no se pretenden hacer en esta tesis
   ESTADO: TERMINADO, EN REVISION

Dado que el lenguaje de programación D_ puede ser enlazado con código
objeto C, y por lo tanto interactuar directamente con éste, habrán
limitaciones en el recolector resultante con respecto a esto. En este
trabajo se busca lograr un recolector que sea eficiente para casos en donde
el código que interactúa con C esté bien aislado, por lo que estas
porciones de código pueden quedar por fuera del recolector de basura o
necesitar un manejo especial.

De no plantear esta limitación se llegaría indefectiblemente a un recolector
conservativo como el que está disponible en la actualidad.

.. ===========================================================================


Recolección de Basura
=====================
.. Introducción a la importancia de la recolección de basura y sus
   principales técnicas, con sus ventajas y desventajas. También se da
   un breve recorrido sobre el estado del arte.
   ESTADO: SIN EMPEZAR


.. ===========================================================================


El Lenguaje de Programación D
=============================
.. Introducción y breve reseña del lenguaje de programación D. También
   se presentan las necesidades particulares de D con respecto al
   recolector de basura y su estado actual.
   ESTADO: SIN EMPEZAR, REVISAR LO HECHO

A continuación se enumeran las principales características de D_,
agrupadas por unidades funcional o paradigmas que soporta:

.. EL LENGUAJE DE PROGRAMACION D .............................................

Programación Genérica
---------------------
- Clases y funciones pueden ser parametrizadas.
- Instanciación implícita de funciones parametrizadas.
- Especialización parcial y explícita.
- Acepta tipos, valores y plantillas como parámetros.
- Acepta cantidad de parámetros variables.
- Soporta *mixins* [#dmixin]_.
- ``if`` estático (``static if``) [#dstaticif]_.
- Inferencia de tipos básica implícita [#dtypeinf]_ y explícita
  (mediante ``typeof``) [#dtypeof]_.
- Expresiones ``is`` [#difexpr]_.
- Iteración sobre colecciones (``foreach``).

.. [#dmixin] *Mixin* tiene significados distintos en varios lenguajes de
   programación. En D_ *mixin* significa tomar una secuencia arbitraria de
   declaraciones e insertarla en el contexto (*scope*) actual. Esto puede
   realizarse a nivel global, en clases, estructuras o funciones. Más
   información en http://www.digitalmars.com/d/mixin.html
.. [#dstaticif] Esta construcción puede verse como similar a la
   directiva del preprocesador de C/C++ ``#if``, pero a diferencia de
   esto, en D_ el ``static if`` tiene acceso a todos los símbolos del
   compilador (constantes, tipos, variables, etc). Más información
   en http://www.digitalmars.com/d/version.html#staticif
.. [#dtypeinf] Si no se especifica un tipo al declarar una variable,
   se infiere del tipo de su inicializador. Más información en
   http://www.digitalmars.com/d/declaration.html#AutoDeclaration
.. [#dtypeof] ``typeof`` permite especificar un tipo
   inferido de una expresión. Más información en
   http://www.digitalmars.com/d/declaration.html#typeof
.. [#difexpr] Las *expresiones ``if``* permiten la compilación condicional
   basada en las características de un tipo. Esto se realiza en favor
   a una técnica utilizada en C++ de realizar *pattern matching*
   sobre los parámetros de las plantillas. Más información en
   http://www.digitalmars.com/d/expression.html#IsExpression

.. EL LENGUAJE DE PROGRAMACION D .............................................

Programación de Bajo Nivel (*system programming*)
-------------------------------------------------
- Compila a código de máquina nativo (no necesita una máquina virtual).
- Provee acceso a *assembly* (y por lo tanto, acceso directo al
  *hardware*).
- ``goto``.
- Soporta todos los tipos de C.
- ABI [#abi]_ compatible con C (genera archivos objeto estándar por lo que
  se puede enlazar con código C).
- Permite manejo de memoria explícito (permitiendo alocar estructuras en
  el *stack* o en el *heap*).
- Objetos *livianos* (no polimórficos) y arreglos *livianos* (estáticos,
  sin *overhead* como C).
- La `programación genérica`_ permite realizar muchas optimizaciones
  ya que se resuelve en tiempo de compilación y por lo tanto aumentando
  la *performance* en la ejecución.
- Número de punto flotante de 80 bits.
- Control de alineación de miembros de una estructura.

.. [#abi] Interfaz de Aplicación Binaria (del inglés *Application Binary
   Interface*).

.. EL LENGUAJE DE PROGRAMACION D .............................................

Programación de Alto Nivel
--------------------------
- Manejo de memoria automática (recolección de basura).
- Sistema de módulos (similar a Python_).
- Funciones y delegados:

  - Son ciudadanos de primera clase [#1stclasscity]_.
  - Pueden ser sobrecargados.
  - Pueden estar anidados.
  - Argumentos de entrada/salida.
  - Argumentos por omisión.
  - Evaluación perezosa (*lazy*) de argumentos.
  - Cantidad de argumentos variables (con tipado seguro).

- Arreglos *dinámicos* (de longitud variable) y arreglos asociativos
  (también conocidos como *hashes* o diccionarios) y son ciudadanos
  de primera clase [#1stclasscity]_, soporta rebanado (*array slicing*
  [#dslicing]_) y chequeo de límites (*bound checking*).
- Soporta *strings* como tipo nativo (con codificación utf-8), incluyendo
  la capacidad de hacer un ``switch`` sobre estos.
- ``alias`` [#dalias]_.
- Documentación embebida.
- Números complejos.

.. [#1stclasscity] Por ciudadano de primera clase se entiende que se
   trata de un tipo soportado por completo por el lenguaje, disponiendo de
   expresiones literales anónimas, pudiendo ser almacenados en variables,
   estructuras de datos, teniendo una identidad intrínseca, más allá
   de un nombre dado, etc. En realidad los arreglos asociativos no pueden
   ser expresados como literales anónimos pero sí tienen una sintaxis
   especial soportada directamente por el lenguaje.
.. [#dslicing] Se refiere a la capacidad de referirse a una porción de
   un arreglo. Profundizaremos sobre esta característica más adelante
   porque es importante a la hora de elegir un método de recolección
   de basura.
.. [#dalias] Análogo al ``typedef`` de C/C++.

.. EL LENGUAJE DE PROGRAMACION D .............................................

Programación Orientada a Objetos
--------------------------------
- Objetos *pesadas* (polimórficos).
- Interfaces.
- Sobrecarga de operadores (con tipos de retorno covariantes [#dcovariant]_).
- Clases anidadas.
- Propiedades [#dprop]_.

.. [#dcovariant] Tipo de retorno covariante se refiere a la
   capacidad de que una función sobreescrita por una clase derivada
   puede retornar un tipo que sea derivado del tipo retornado
   por la función original sobreescrita. Más información en
   http://www.digitalmars.com/d/function.html
.. [#dprop] En D_ se refiere a funciones miembro que pueden ser tratadas
   sintácticamente como campos de esa clase/estructura. Más información
   en http://www.digitalmars.com/d/property.html#classproperties

.. EL LENGUAJE DE PROGRAMACION D .............................................

Programación Confiable
----------------------
- Diseño por contrato [#ddbc]_:

  - Precondiciones.
  - Postcondiciones.
  - Invariantes de representación.
  - Afirmaciones (*asserts*).

- Pruebas unitarias.
- Orden de construcción estática (inicialización de módulos) determinado.
- Inicialización garantizada.
- RAII [#draii]_ (*Resource adquisition is initialization*).
- Guardias de contexto (*scope guards*).
- Excepciones (con ``try``, ``catch`` y ``finally``).
- Primitivas de sincronización de hilos (``synchronized``).

.. [#ddbc] El diseño por contrato es un concepto creado por Eiffel_ a
   mediados/finales de los '80. Más información sobre el soporte de D_ en
   http://www.digitalmars.com/d/dbc.html
.. [#draii] Es una técnica muy utilizada en C++ que consiste en reservar
   recursos por medio de la construcción de un objeto y liberarlos cuando
   se libera éste. Al llamarse al destructor de manera automática cuando
   se sale del *scope*, se asegura que el recurso será liberado también.
   Esta técnica es la base para desarrollar código seguro en cuanto a
   excepciones (*exception-safe*) [SUTT99]_.

.. _Eiffel: http://www.eiffel.com/


.. ===========================================================================


Definición del Problema
=======================
.. Describe más detalladamente los problemas actuales del recolector de
   basura de D, sentando las bases para el análisis de los requerimientos
   de recolección de basura en dicho lenguaje (se explica por qué las
   particularidades descriptas en la sección anterior complican la
   recolección de basura).
   ESTADO: SIN EMPEZAR, REVISAR LO HECHO

Como se ha visto, D_ es un lenguaje de programación muy completo,
pero aún tiene algunos aspectos inconclusos. Su recolector de basura
está en un estado de evolución muy temprana. Se trata de un marcado y
barrido (*mark and sweep*) conservativo que, en ciertas circunstancias,
no se comporta como es debido, ya que revisa toda la memoria del programa
en busca de referencias a objetos en el *heap* (en vez de revisar sólo
las partes que almacenan punteros). Esto produce que, en ciertos casos,
por ejemplo al almacenar arreglos de número o *strings* en la pila, el
recolector de basura se encuentre con *falsos positivos*, pensando que
un área del *heap* está siendo utilizada cuando en realidad el puntero
que hacía referencia a ésta no era tal. Este efecto puede llevar a la
pérdida de memoria masiva, llegando al límite de que eventualmente
el sistema operativo tenga que matar al programa por falta de memoria
[DNG46407]_. Aún cuando el programa no tenga estos problemas de por sí,
por usar datos que no pueden ser confundidos con direcciones de memoria,
este problema podría ser explotado por ataques de seguridad, inyectando
valores que sí sean punteros válidos y provocando el efecto antes
mencionado que deriva en la terminación abrupta del programa [DNG35364]_.
Finalmente, a estos problemas se suman los problemas de *performance*
[DNG43991]_.

Es difícil que D_ pueda ser un lenguaje de programación exitoso si
no provee un recolector de basura eficiente y que realmente evite la
pérdida masiva de memoria. Por otro lado, D_ podría atraer a una base de
usuarios mucho más amplia, si la gama de estrategias de recolección es
más amplia, pudiendo lograr adaptarse a más casos de uso sin llegar al
límite de tener que caer en el manejo explícito de memoria y perder por
completo las ventajas de la recolección de basura (con la consecuencia
ya mencionada de que el manejo de memoria tenga que pasar a ser parte
de las interfaces y la complejidad que esto agrega al diseño -y uso-
de una biblioteca).


.. ===========================================================================


Análisis de la Solución
=======================
.. Describe los resultados del análisis y explica los fundamentos para
   elegir los algoritmos seleccionados para implementar, en base a los
   requerimientos hallados anteriormente.
   ESTADO: SIN EMPEZAR, REVISAR LO HECHO

.. ANALISIS DE LA SOLUCION ...................................................

Soluciones Propuestas
---------------------
Para poder implementar un recolector de basura no conservativo es
necesario disponer de un soporte de reflexión (en tiempo de compilación
[DNG44607]_ y de ejecución [DNG29291]_) bastante completo . De otra forma
es imposible distinguir si un área de memoria de la pila es utilizada
como un puntero o como un simple conjunto de datos. D_ provee algún
grado de reflexión, pero muy limitado como para poder obtener este
tipo de información. Ya hay un plan para agregar mayores capacidades
de reflexibilidad [DNG6842]_, y un pequeño avance en este sentido en la
`versión 1.001`_, pero con algunos problemas [DNG6890]_ [DNG6893]_.

.. _`versión 1.001`: http://www.digitalmars.com/d/changelog.html#new1_001

Se han propuesto otros métodos e implementaciones de recolector de
basura, por ejemplo colectores con movimiento (*moving collectors*)
[DNG42557]_ y conteo de referencias [DNG38689]_. Pero D_ es un
lenguaje muy particular en cuanto a la recolección de basura (al
permitir `programación de bajo nivel (system programming)`_ hay muchas
consideraciones a las que otros lenguajes no deben enfrentarse) y no es
sencillo pensar en otras implementaciones sin hacer modificaciones de
base al lenguaje.

.. ANALISIS DE LA SOLUCION ...................................................

Problemas para Implementar Colectores con Movimiento
----------------------------------------------------
El principal problema es la capacidad de D_ de manipular punteros y
otras estructuras de bajo nivel, como uniones. O incluso la capacidad
de interactuar con C. Al mover un objeto de un área de memoria a otro,
es necesario actualizar todos los punteros que apuntan a éste. En D_
esta tarea no es trivial [DNG42564]_

.. ANALISIS DE LA SOLUCION ...................................................

Problemas para Implementar Conteo de Referencias
------------------------------------------------
Este tipo de recolectores reparten la carga de la recolección de forma
uniforme a lo largo (y a la par) de la ejecución del programa. El
problema principal para implementar este tipo de recolección es
la necesidad de soporte en el compilador (cada asignación debe ser
acompañada por el incremento/decremento de contadores de referencia), a
menos que se implemente en una biblioteca. Por otro lado, características
como el rebanado de arreglos (ver `Programación de Alto Nivel`_) son
difíciles de proveer con el conteo de referencias, entre otros problemas
[DNG38704]_.


.. ===========================================================================


Implementación de la solución:
==============================
.. Describe el diseño e implementación de los algoritmos
   seleccionados. Se detalla si la solución se implementa como
   biblioteca o si fue necesario modificar el compilador y de ser así
   si se modificó el *frontend* o el GDC y se comentan problemas y
   limitaciones encontradas.
   ESTADO: SIN EMPEZAR


.. ===========================================================================


Conclusiones
============
.. Se presentan las conclusiones del trabajo, comparando los resultados
   obtenidos con el punto de partida. Se mencionan puntos pendientes o
   nuevas líneas de investigación.
   ESTADO: SIN EMPEZAR




.. ===========================================================================
.. ============================ FIN DEL DOCUMENTO ============================
.. ===========================================================================

.. Pone links "offline" (para generar PDF para imprimir).
.. .. target-notes::

.. Macros:
.. |date| date:: %e de %B de %Y

.. Citas:
.. [JOLI96] Richard Jones, Rafael D Lins. Garbage Collection: Algorithms
   for Automatic Dynamic Memory Management. John Wiley & Sons, 1996.
   ISBN 0-471-94148-4.
.. [SUTT99] Herb Sutter. Exceptional C++: 47 Engineering Puzzles,
   Programming Problems, and Solutions, 1ra edición. Addison-Wesley
   Professional, 1999. ISBN 0-201-61562-2.
.. [DNG46407] Oskar Linde. The problem with the D GC. Grupo de noticias
   digitalmars.D, 8 de enero de 2007. `Mensaje número 46407`_.
.. _`Mensaje número 46407`: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=46407
.. [DNG43991] Andrey Khropov. [Performance] shootout.binarytrees when
   implemented with gc is 10x slower than C# on .NET 2.0. Grupo de noticias
   digitalmars.D, 11 de noviembre de 2006. `Mensaje número 43991`_.
.. _`Mensaje número 43991`: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=43991
.. [DNG35364] Frank Benoit. GC implementation. Grupo de noticias
   digitalmars.D, 18 de marzo de 2006. `Mensaje número 35364`_.
.. _`Mensaje número 35364`: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=35364
.. [DNG44607] Russ Lewis. A TODO for somebody: Full Reflection Gets You
   Smarter GC. Grupo de noticias digitalmars.D, 20 de noviembre de
   2006. `Mensaje número 44607`_.
.. _`Mensaje número 44607`: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=44607
.. [DNG29291] Larry Evans. How does RTTI help gc?. Grupo de noticias
   digitalmars.D, 21 de octubre de 2005. `Mensaje número 29291`_.
.. _`Mensaje número 29291`: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=29291
.. [DNG6842] Walter Bright. Transitioning to a type aware Garbage
   Collector. Grupo de noticias digitalmars.D.announce, 22 de enero de
   2007. `Mensaje número 6842`_.
.. _`Mensaje número 6842`: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.announce&article_id=6842
.. [DNG42557] Lionello Lunesu. Is a moving GC really needed?. Grupo de
   noticias digitalmars.D, 2 de octubre de 2006. `Mensaje número 42557`_.
.. _`Mensaje número 42557`: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=42557
.. [DNG38689] Frank Benoit. GC, the simple solution. Grupo de noticias
   digitalmars.D, 4 de junio de 2006. `Mensaje número 38689`_.
.. _`Mensaje número 38689`: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=38689
.. [DNG42564] xs0. Re: Is a moving GC really needed?. Grupo de noticias
   digitalmars.D, 2 de octubre de 2006. `Mensaje número 42564`_.
.. _`Mensaje número 42564`: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=42564
.. [DNG38704] Walter Bright. Re: GC, the simple solution. Grupo de
   noticias digitalmars.D, 4 de junio de 2006. `Mensaje número 38704`_.
.. _`Mensaje número 38704`: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=38704
.. [DNG6890] Lionello Lunesu. std.string.split is broken :( (Re: DMD 1.001
   release). Grupo de noticias digitalmars.D.announce, 24 de enero de
   2007. `Mensaje número 6890`_.
.. _`Mensaje número 6890`: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.announce&article_id=6890
.. [DNG6893] Oskar Linde. Re: DMD 1.001 release. Grupo de noticias
   digitalmars.D.announce, 24 de enero de 2007. `Mensaje número 6893`_.
.. _`Mensaje número 6893`: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.announce&article_id=6893
.. [HDH03] Martin Hirzel, Amer Diwan, and Matthew Hertz, Proceedings
   of the 18th Conference on Object-Oriented Programming, Systems,
   Languages, and Applications (OOPSLA 2003), Anaheim, CA, Oct. 26-30,
   2003.
.. [LINS05] Rafael D Lins. A New Multi-Processor Architecture for
   Parallel Lazy Cyclic Reference Counting. Proceedings of the 17th
   International Symposium on Computer Architecture on High Performance
   Computing - Volume 00 (páginas 35-43), 2005.

.. vim: set ts=2 sts=2 sw=2 et tw=75 :