From 9a45b57ffa336bc98afde3379c3da1368704fbb0 Mon Sep 17 00:00:00 2001 From: Leandro Lucarella Date: Thu, 25 Jan 2007 15:49:40 +0000 Subject: [PATCH] =?utf8?q?Primera=20revisi=C3=B3n=20de=20la=20propuesta=20?= =?utf8?q?de=20tesis.?= MIME-Version: 1.0 Content-Type: text/plain; charset=utf8 Content-Transfer-Encoding: 8bit --- .p.pl.swp | Bin 0 -> 12288 bytes Makefile | 37 ++++ propuesta.rst | 567 ++++++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 604 insertions(+) create mode 100644 .p.pl.swp create mode 100644 Makefile create mode 100644 propuesta.rst diff --git a/.p.pl.swp b/.p.pl.swp new file mode 100644 index 0000000000000000000000000000000000000000..d5c43ab5caea1156c0837a9c2465fc94f3cc3005 GIT binary patch literal 12288 zcmeI1O>f*p7{@1YCh%*;1fcOS{0Hhwv4Z(jro3`PSOAiQ*rJtXjXJ(#x=0A@|RnxC; zx7O)$b(Z0Ifw6P+zy6|f3e1*`&A0jq#j;6JZ`N+#If$nptr z1x$>Av5!^2Dqt0`3RnfK0#*U5fK|XMU=^?mSOu&C{}Tm-$Jnd*TmQm&YzTk<*Z&7_ z?|H_)1>XP#I9LErf(h`$bBuitJ_23P0V`kuOo5lcIq=5?#(o1|flt9F;10L}u7fwg zRq*GtjNJ#ngI~bU;A1ckE&&1;!C%iX_7gY;uYvndGxjz35_|zZ2cLmk;5v94OoRK_ z+ppj|pujtz4PFO&-fREiU|)1jjynyuICi>#ES@g3=^Vix+HnnP7O?F|N0KINHSEJFWl zY7x4vLpxYpuiZ~Y1Jh}QaO}&_0J^|x$@(5XAp!^JG%O{qF-%# zR4jP9+Z#JuoweH!qj^V_Wj!>|uUx-U{c2G#jN%lcgi@cZ_GOeQk*XcnA3hSGL94Ca z4$eEy0u`qRdZZ#Kax$$)g@7l`KAB@E+7I)H$L`7?PAhLUmx`o(9c)j(LK=y?Sfyxm zu=%3Aq`*1DncZevT6#{U!&`lk6)97xeq3laNdu`|zm_MSP*SH$gESry#9-%55qEpb z%}$4|T!GSyEX(^R2SJDU$2T5RWiy58;6xty`o@i1&nB16#F@Z57W7dsP#`IXN^52t!JrjD;VTfGKqvea#@9!|Ae?WXp% zRyQ^~OTX*=jd9-%MmQXWH$}ZtFezV85KHbfAKfBri|qps1eP+T^?)B;%<) z^m4uyyCO8*D=0?JubrGPf;>2DFGzJkjpLYsZJ~U<(r7oquTxz;IZAYwg4HE{sx!n=aOf zLmj|{!q}v*sO(PDT)jR&L+e5*KM)yhrHJBV!JM!`ggxp}OEq "$@" + +$(docname).$(html): $(docname).$(rst) + @echo "Generando $@..." + @rst2html $(rstopts) $(htmlopts) "$(basename $@).$(rst)" > "$@" + +$(docname).pdf: $(docname).$(latex) + @echo "Generando $@..." + @pdflatex "$(basename $@).$(latex)" > /dev/null + @pdflatex "$(basename $@).$(latex)" > /dev/null + +clean-tmp: + @$(RM) $(docname).aux $(docname).out $(docname).log + @$(RM) $(docname).toc texput.log + +clean: clean-tmp + @$(RM) -fv $(targets) $(docname).latex + +.PHONY: clean all + diff --git a/propuesta.rst b/propuesta.rst new file mode 100644 index 0000000..df0cd71 --- /dev/null +++ b/propuesta.rst @@ -0,0 +1,567 @@ + + +========================== +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 : -- 2.43.0