--- /dev/null
+
+
+==========================
+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 :
projects / z.facultad / 75.00 / propuesta.git / commitdiff