Primera revisión de la propuesta de tesis.

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

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


------------------
Propuesta de 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
============
.. FIXME No me gusta como están redactados estos dos párrafos :S

Los lenguajes modernos tienen una tendencia cada vez más marcada a
adoptar técnicas cada vez más 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 empresarial o bien eran
muy lentos por la baja capacidad de procesamiento de la época o eran
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 el concepto de recolección de basura 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 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.


El Lenguaje de Programación D_
------------------------------
D_ es un lenguaje de programación joven. Nació en 1999 y el 2 de enero
de 2007 salió su `versión 1.0`_, aunque han quedado algunas cosas
importantes en el tintero. Su creador, `Walter Bright`_, desarrollador
principal de Zortech C++, el primer compilador de C++ 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.

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 sintáxis 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. 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.

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


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 condicinal
   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


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*).


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++.


Programación Orientada a Objetos
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
- Obejetos *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


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]_.


Importancia de la Recolección de Basura
---------------------------------------
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 inegable 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, oscuras de por sí y tienden a perder
abstracción y a depender del *hardware* y otras particularidades.

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.


Problema
========
Como se ha visto, D_ es un lenguaje de programación muy completo,
pero aún tiene algúnos 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).

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]_.

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.

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]_

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]_.


Objetivo
========
De acuerdo al problema planteado, el objetivo de la presente trabajo
será:

- 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 desarollo 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 fehasible 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.

Alcance
-------
Las ténicas de recolección de basura que se analizarán en este trabajo
incluirán, pero no se limitarán a:

- Conteo de referencia (*reference counting*).
- Marcado y compactado (*mark-compact*).
- Por copia (*copying collector*).
- Generacional (*generational garbage collector*).
- Técnicas híbridas.

Algunos ejemplos particulares de algoritmos a analizar son:

- VZOOM_ (*Virtually Zero Overhead Object Management*).
- CBGC_ (*Connectivity-based Garbage Collection*) [HDH03]_.
- Conteo de referencias perezoso en paralelo (*A New Multi-Processor
  Architecture for Parallel Lazy Cyclic Reference Counting*) [LINS05]_.

Todo esto será analizado dentro del contexto, limitaciones y
requerimientos del lenguaje de programación D_. Del análisis realizado
se seleccionarán los algoritmos más viables para su implementación y
realizar pruebas reales para obtener resultados sobre su comportamiento,
en distintos escenarios de uso.


Organización
============
El trabajo se encontrará dividido en una serie de capítulos, los cuales se
describen brevemente a continuación:

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

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.

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.

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.

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.

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.

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.


Cronograma
==========
========================================== ======== ======== ========
                Actividad                  Esfuerzo  Inicio    Fin
========================================== ======== ======== ========
Investigación y definición de objetivos      176 hs Feb 2006 Dic 2006
Confección del documento de propuesta         48 hs Ene 2007 Feb 2007
Análisis de las posibles soluciones           96 hs Dic 2006 May 2007
Desarrollo de las soluciones elegidas        240 hs Abr 2007 Dic 2007
Confección de la Tesis                       240 hs Sep 2007 Dic 2007
Confección del material para la exposición    52 hs Nov 2007 Dic 2007
========================================== ======== ======== ========

.. note::
   Tanto las horas de esfuerzo como las fechas de inicio y fin son
   tentativas y por lo tanto aproximadas. Debido a la finalización de la
   cursada al término del primer cuatrimestre de 2007, la dedicación
   aumentará considerablemente durante el segundo cuatrimestre de 2007 (por
   ello la diferencia de horas entre ambos períodos).


.. FIN DOCUMENTO


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

.. Links:
.. _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
.. _D: http://www.digitalmars.com/d/
.. _`versión 1.0`: http://www.digitalmars.com/d/changelog2.html#new1_00
.. _`versión 1.001`: http://www.digitalmars.com/d/changelog.html#new1_001
.. _`Walter Bright`: http://www.walterbright.com/
.. _Eiffel: http://www.eiffel.com/
.. _GDC: http://dgcc.sourceforge.net/
.. _DigitalMars: http://www.digitalmars.com/
.. _DMD: http://www.digitalmars.com/d/dcompiler.html
.. _GCC: http://gcc.gnu.org/
.. _`Mensaje número 46407`: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=46407
.. _`Mensaje número 43991`: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=43991
.. _`Mensaje número 35364`: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=35364
.. _`Mensaje número 44607`: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=44607
.. _`Mensaje número 29291`: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=29291
.. _`Mensaje número 6842`: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.announce&article_id=6842
.. _`Mensaje número 42557`: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=42557
.. _`Mensaje número 38689`: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=38689
.. _`Mensaje número 42564`: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=42564
.. _`Mensaje número 38704`: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=38704
.. _`Mensaje número 6890`: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.announce&article_id=6890
.. _`Mensaje número 6893`: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.announce&article_id=6893
.. _CBGC: http://www.cs.colorado.edu/%7Ediwan/cbgc.pdf
.. _VZOOM: http://home.comcast.net/~vzoom/

.. 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`_.
.. [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`_.
.. [DNG35364] Frank Benoit. GC implementation. Grupo de noticias
   digitalmars.D, 18 de marzo de 2006. `Mensaje número 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`_.
.. [DNG29291] Larry Evans. How does RTTI help gc?. Grupo de noticias
   digitalmars.D, 21 de octubre de 2005. `Mensaje número 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`_.
.. [DNG42557] Lionello Lunesu. Is a moving GC really needed?. Grupo de
   noticias digitalmars.D, 2 de octubre de 2006. `Mensaje número 42557`_.
.. [DNG38689] Frank Benoit. GC, the simple solution. Grupo de noticias
   digitalmars.D, 4 de junio de 2006. `Mensaje número 38689`_.
.. [DNG42564] xs0. Re: Is a moving GC really needed?. Grupo de noticias
   digitalmars.D, 2 de octubre de 2006. `Mensaje número 42564`_.
.. [DNG38704] Walter Bright. Re: GC, the simple solution. Grupo de
   noticias digitalmars.D, 4 de junio de 2006. `Mensaje número 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`_.
.. [DNG6893] Oskar Linde. Re: DMD 1.001 release. Grupo de noticias
   digitalmars.D.announce, 24 de enero de 2007. `Mensaje número 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 :