From: Leandro Lucarella Date: Fri, 24 Sep 2010 23:20:40 +0000 (-0300) Subject: Eliminar : al final del término en listas de definición X-Git-Tag: entrega-2010-10-08~21 X-Git-Url: https://git.llucax.com/z.facultad/75.00/informe.git/commitdiff_plain/21f5e573dc375b4f716798b3aeec945a62e8891d Eliminar : al final del término en listas de definición --- diff --git a/source/d.rst b/source/d.rst index 8db6f00..0dc123d 100644 --- a/source/d.rst +++ b/source/d.rst @@ -190,7 +190,7 @@ Python_). D_ provee las siguientes herramientas para realizar programación genérica y meta-programación: -``if`` estático (``static if``): +``if`` estático (``static if``) 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). @@ -202,7 +202,7 @@ y meta-programación: Más información en http://www.digitalmars.com/d/1.0/version.html#staticif -Inferencia de tipos básica implícita y explícita (mediante ``typeof``): +Inferencia de tipos básica implícita y explícita (mediante ``typeof``) si no se especifica un tipo al declarar una variable, se infiere del tipo de su valor de inicialización. @@ -224,7 +224,7 @@ Inferencia de tipos básica implícita y explícita (mediante ``typeof``): Más información en http://www.digitalmars.com/d/1.0/declaration.html#typeof -Iteración sobre colecciones (``foreach``): +Iteración sobre colecciones (``foreach``) cualquier tipo de colección (arreglos estáticos y dinámicos, arreglos asociativos, clases, estructuras o delegados) puede ser iterada mediante la sentencia ``foreach``. @@ -236,7 +236,7 @@ Iteración sobre colecciones (``foreach``): foreach (i; a) total += i; -*Templates*: +*Templates* clases y funciones pueden ser generalizadas. Esto permite desarrollar algoritmos genéricos sin importar el tipo de los datos de entrada, siempre y cuando todos los tipos tengan una *interfaz* común. Esto también es @@ -268,7 +268,7 @@ Iteración sobre colecciones (``foreach``): La utilidad más prominente de los bloques generalizados se da al acompañarse de *mixins*. -Instanciación implícita de funciones generalizadas: +Instanciación implícita de funciones generalizadas el lenguaje es capaz de deducir los parámetros siempre que no hayan ambigüedades. @@ -277,7 +277,7 @@ Instanciación implícita de funciones generalizadas: auto i = sumar(5, 6); // i == 11 auto f = sumar(5.0f, 6.0f); // f == 11.0f -Especialización explícita y parcial de *templates*: +Especialización explícita y parcial de *templates* la especialización de *templates* consiste, al igual que en C++, en proveer una implementación especializada para un tipo de dato (o valor) de los parámetros. Especialización parcial se refiere a la capacidad de @@ -300,7 +300,7 @@ Especialización explícita y parcial de *templates*: float v = 5.0f, w = 6.0f; auto f = sumar(&v, &w); // f == 11.0f -Tipos, valores (incluyendo *strings*) y *templates* como parámetros: +Tipos, valores (incluyendo *strings*) y *templates* como parámetros esto es otro bloque de construcción importantísimo para la programación genérica en D, ya que combinando *templates* que toman *strings* como parámetro en combinación con *string mixins* pueden hacerse toda clase de @@ -316,7 +316,7 @@ Tipos, valores (incluyendo *strings*) y *templates* como parámetros: } string s = hash!("hola"); // calculado en tiempo de compilación -Cantidad de parámetros variables para *templates*: +Cantidad de parámetros variables para *templates* Esto permite implementar tuplas u otros algoritmos que inherentemente deben tomar una cantidad variable de parámetros en tiempo de compilación. @@ -330,7 +330,7 @@ Cantidad de parámetros variables para *templates*: } double d = sumar(1, 2.0, 3.0f, 4l); // d == 10.0 -*CTFE* (*compile-time function execution*): +*CTFE* (*compile-time function execution*) si una función cumple ciertas reglas básicas (como por ejemplo no tener efectos colaterales) puede ser ejecutada en tiempo de compilación en vez de tiempo de ejecución. Esto permite hacer algunos cálculos que no cambian de @@ -351,7 +351,7 @@ Cantidad de parámetros variables para *templates*: Esta característica es vital para evitar la duplicación de código. -*Mixins*, incluyendo *string mixins*: +*Mixins*, incluyendo *string mixins* la palabra *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 @@ -393,7 +393,7 @@ Cantidad de parámetros variables para *templates*: Más información en http://www.digitalmars.com/d/1.0/mixin.html -Expresiones ``is``: +Expresiones ``is`` las *expresiones ``is``* 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 @@ -426,11 +426,11 @@ el lenguaje de bajo nivel más popular, seguido por C++. D_ presenta muchas características de bajo nivel: -Compila a código de máquina nativo: +Compila a código de máquina nativo no es interpretado ni necesita una máquina virtual como otros lenguajes de más alto nivel como Java_, `C#`_, Python_, etc. -Provee acceso a *assembly*: +Provee acceso a *assembly* por lo tanto, acceso directo al *hardware* y la posibilidad de utilizar cualquier característica de éste que no esté disponible en el lenguaje. @@ -439,10 +439,10 @@ Provee acceso a *assembly*: compiladores incluso cuando se utiliza *assembly* (mientras que no se cambie de arquitectura, por supuesto). -``goto``: +``goto`` al igual que C y C++, D_ provee la flexibilidad del uso de ``goto``. -Compatibilidad con C: +Compatibilidad con C soporta todos los tipos de C y es ABI [#abi]_ compatible con éste. Esto permite enlazar archivos objeto estándar de C y D_ en un mismo programa. Además permite interoperar con C a través de ``extern (C)``. @@ -455,11 +455,11 @@ Compatibilidad con C: extern (C) printf(const char* format, ...); printf("3 + 5 == %d\n", 3 + 5); // llama al printf de C -Manejo de memoria explícito: +Manejo de memoria explícito permite asignar estructuras en el *stack* o en el *heap*, haciendo uso de los servicios del sistema operativo o la biblioteca estándar de C. -Objetos y arreglos *livianos*: +Objetos y arreglos *livianos* por objetos *livianos* se entiende no-polimórficos. Es decir, un agrupamiento de variables análogo al ``struct`` de C, sin tabla virtual ni otro tipo de *overhead*. Los arreglos *livianos* son arreglos estáticos @@ -488,16 +488,16 @@ Objetos y arreglos *livianos*: timeval tv; gettimeofday(&tv, null); -Rendimiento: +Rendimiento la :ref:`d_generic` permite realizar muchas optimizaciones ya que se resuelve en tiempo de compilación y por lo tanto aumenta el rendimiento en la ejecución. -Número de punto flotante de 80 bits: +Número de punto flotante de 80 bits El tipo ``real`` de D_ tiene precisión de 80 bits si la plataforma lo soporta (por ejemplo en i386). -Control de alineación de miembros de una estructura: +Control de alineación de miembros de una estructura Mediante ``align`` se puede especificar la alineación a tener en una estructura. @@ -527,13 +527,13 @@ En general estas características tienen como efecto secundario una mejora de la productividad de los programadores. D_ adopta herramientas de muchos lenguajes de alto nivel, como Java_ y Python_, por ejemplo: -Manejo automático de memoria: +Manejo automático de memoria al igual que C/C++ y prácticamente cualquier lenguaje imperativo maneja automáticamente el *stack*, pero a diferencia de la mayoría de los lenguajes de bajo nivel, D_ permite manejar el *heap* de manera automática también a través de un *recolector de basura*. -Sistema de paquetes y módulos (similar a Java_ o Python_): +Sistema de paquetes y módulos (similar a Java_ o Python_) un módulo es una unidad que agrupa clases, funciones y cualquier otra construcción de lenguaje. Un paquete es una agrupación de módulos. D_ asocia un módulo a un archivo fuente (y un archivo objeto cuando éste es @@ -562,7 +562,7 @@ Sistema de paquetes y módulos (similar a Java_ o Python_): b.f(); f(); // ejecuta b.f() -Funciones y delegados: +Funciones y delegados las funciones pueden ser sobrecargadas (funciones con el mismo nombre pero distinta cantidad o tipo de parámetros), pueden especificarse argumentos de entrada, salida o entrada/salida, argumentos por omisión o argumentos @@ -609,7 +609,7 @@ Funciones y delegados: } ); -Arreglos *dinámicos* y arreglos asociativos: +Arreglos *dinámicos* y arreglos asociativos los arreglos *dinámicos* son arreglos de longitud variable manejados automáticamente por el lenguaje (análogos al ``std::vector`` de C++). Soportan concatenación (a través del operador ``~``), rebanado o *slicing* @@ -628,7 +628,7 @@ Arreglos *dinámicos* y arreglos asociativos: int[string] agenda; agenda["Pepe"] = 5555_1234; -*Strings*: +*Strings* al igual que los delegados y arreglos dinámicos y asociativos, los *strings* son ciudadanos de primera clase, teniendo forma literal y siendo codificados en UTF-8/16/32. Son un caso particular de arreglo dinámico y es @@ -645,7 +645,7 @@ Arreglos *dinámicos* y arreglos asociativos: s = ""; } -``typedef`` y ``alias``: +``typedef`` y ``alias`` el primero define un nuevo tipo basado en otro. A diferencia de C/C++ el tipo original no puede ser implícitamente convertido al tipo nuevo (excepto valores literales), pero la conversión es válida en el otro sentido @@ -665,7 +665,7 @@ Arreglos *dinámicos* y arreglos asociativos: un_alias a = t; foo(a); -Documentación embebida: +Documentación embebida D_ provee un sistema de documentación embebida, análogo a lo que proveen Java_ o Python_ en menor medida. Hay comentarios especiales del código que pueden ser utilizados para documentarlo de forma tal que luego el @@ -673,7 +673,7 @@ Documentación embebida: Más información en http://www.digitalmars.com/d/1.0/ddoc.html -Números complejos: +Números complejos D_ soporta números complejos como ciudadanos de primera clase. Soporta forma literal de números imaginarios y complejos. @@ -693,7 +693,7 @@ actualidad a la hora de diseñar e implementar un programa. D_ provee muchas herramientas para soportar este paradigma de forma confiable. Entre las características más salientes se encuentran: -Objetos *pesados*: +Objetos *pesados* objetos polimórficos como los de cualquier lenguaje con orientación real a objetos. Estos objetos poseen una tabla virtual para despacho dinámico, todos los métodos son virtuales a menos que se indique lo contrario @@ -735,7 +735,7 @@ Objetos *pesados*: Más información en http://www.digitalmars.com/d/1.0/function.html -Interfaces: +Interfaces D_ no soporta herencia múltiple pero sí interfaces. Una interfaz es básicamente una tabla virtual, una definición de métodos virtuales que debe proveer una clase. Las interfaces no proveen una implementación de dichos @@ -745,12 +745,12 @@ Interfaces: implementación o atributos en común a varias clases que implementan la misma interfaz. -Sobrecarga de operadores: +Sobrecarga de operadores la sobrecarga de operadores permite que un objeto tenga una sintaxis similar a un tipo de dato nativo. Esto es muy importante además para la programación genérica. -Clases anidadas: +Clases anidadas al igual que C (con respecto a ``struct``) y C++, pueden anidarse clases dentro de clases. D_ sin embargo provee la posibilidad de acceder a atributos de la instancia exterior desde la anidada. @@ -785,7 +785,7 @@ Clases anidadas: } -Propiedades (*properties*): +Propiedades (*properties*) en D_ se refiere a funciones miembro que pueden ser tratadas sintácticamente como campos de esa clase/estructura. @@ -803,21 +803,21 @@ Propiedades (*properties*): Además tipos nativos, clases, estructuras y expresiones tienen *properties* predefinidos, por ejemplo: - ``sizeof``: + ``sizeof`` tamaño ocupado en memoria (ejemplo: ``int.sizeof`` -> 4). - ``init``: + ``init`` valor de inicialización por omisión (ejemplo: ``float.init`` -> *NaN* [#dnan]_). .. [#dnan] Del inglés *Not A Number*, es un valor especial que indica que estamos ante un valor inválido. - ``stringof``: + ``stringof`` representación textual del símbolo o expresión (ejemplo: ``(1+2).stringof`` -> ``"1 + 2"``). - ``mangleof``: + ``mangleof`` representación textual del tipo *mutilado* [#dmangle]_. .. [#dmangle] *Name mangling* es el nombre dado comunmente a una técnica @@ -850,12 +850,12 @@ el lenguaje para evitar fallas de manera temprano (o la capacidad de evitar que ciertas fallas puedan existir directamente). D_ presta particular atención a esto y provee las siguientes herramientas: -Excepciones: +Excepciones D_ soporta excepciones de manera similar a Java_: provee ``try``, ``catch`` y ``finally``. Esto permite que los errores difícilmente pasen silenciosamente sin ser detectados. -``assert``: +``assert`` es una condición que debe cumplirse siempre en un programa, como un chequeo de integridad. Esto es muy utilizado en C/C++, donde ``assert()`` es una *macro* que solo se compila cuando la *macro* ``NDEBUG`` no está definida. @@ -871,7 +871,7 @@ Excepciones: File f = open("archivo"); assert (f.ok()); -Diseño por contrato: +Diseño por contrato el diseño por contrato es un concepto introducido por el lenguaje Eiffel_ a mediados/finales de los '80. Se trata de incorporar en el lenguaje las herramientas para poder aplicar verificaciones formales a las interfaces de @@ -881,7 +881,7 @@ Diseño por contrato: ejecutan siempre y cuando no se compile en modo *release*, de manera de no sacrificar rendimiento cuando es necesario): - Pre y post condiciones: + Pre y post condiciones Ejemplo:: double raiz_cuadrada(double x) @@ -901,7 +901,7 @@ Diseño por contrato: // implementación } - Invariantes de representación: + Invariantes de representación La invariante de representación es un método de una clase o estructura que es verificada cuando se completa su construcción, antes de la destrucción, antes y después de ejecutar cualquier función miembro @@ -921,7 +921,7 @@ Diseño por contrato: Más información en http://www.digitalmars.com/d/1.0/dbc.html -Pruebas unitarias: +Pruebas unitarias es posible incluir pequeñas pruebas unitarias en el lenguaje. Éstas son ejecutadas (cuando no se compila en modo *release*) al comenzar el programa, antes de que la función ``main()``. @@ -935,7 +935,7 @@ Pruebas unitarias: assert (fecha); } -Orden de construcción estática: +Orden de construcción estática a diferencia de C++, D_ garantiza el orden de inicialización de los módulos. Si bien en C++ no hay módulos si no unidades de compilación, es posible que se ejecute código antes del ``main()`` en C++, si hay, por @@ -944,7 +944,7 @@ Orden de construcción estática: el orden de inicialización y es el mismo orden en que el usuario importa los módulos. -Inicialización garantizada: +Inicialización garantizada todas las variables son inicializadas por el lenguaje (a menos que el usuario pida explícitamente que no lo sean). Siempre que sea posible se elijen valores de inicialización que permitan saber al programador que la @@ -959,7 +959,7 @@ Inicialización garantizada: byte[5] a; // inicializados todos los valores a 0 long l = void; // NO inicializado (explícitamente) -*RAII* (*Resource Adquisition Is Initialization*): +*RAII* (*Resource Adquisition Is Initialization*) 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*, @@ -985,7 +985,7 @@ Inicialización garantizada: // uso de archivo } // en este punto se llama al destructor de archivo -Guardias de bloque (*scope guards*): +Guardias de bloque (*scope guards*) además de poder limitar la vida de una instancia a un *scope*, es posible especificar un bloque de código arbitrario a ejecutar al abandonar un *scope*, ya sea cuando se sale del *scope* normalmente o por una falla. @@ -1012,7 +1012,7 @@ Guardias de bloque (*scope guards*): el programador debe tener un poco más de cuidado de especificar las acciones a ejecutar al finalizar el *scope*. -Primitivas de sincronización de hilos: +Primitivas de sincronización de hilos la programación multi-hilo está directamente soportada por el lenguaje, y se provee una primitiva de sincronización al igual que Java_. La palabra reservada ``synchronized`` puede aparecer como modificador de métodos (en diff --git a/source/dgc.rst b/source/dgc.rst index 85ff7b4..1c0b84b 100644 --- a/source/dgc.rst +++ b/source/dgc.rst @@ -337,11 +337,11 @@ Atributos de *pool* ^^^^^^^^^^^^^^^^^^^ Cada *pool* tiene la siguiente información asociada: -*number_of_pages*: +*number_of_pages* cantidad de páginas que tiene. Esta cantidad es fija en toda la vida de un *pool*. -*pages*: +*pages* bloque de memoria contiguo de tamaño ``PAGE_SIZE * number_of_pages`` (siendo ``PAGE_SIZE`` el tamaño de página, que normalmente son 4096 bytes). @@ -356,13 +356,13 @@ Una página siempre almacena bloques del mismo tamaño, que pueden ser 16, 32, ``PAGE``). Además hay dos tamaños de bloque simbólicos que tienen un significado especial: -``FREE``: +``FREE`` indica que la página está completamente libre y que la página está disponible para albergar cualquier tamaño de bloque que sea necesario (pero una vez que se le asignó un nuevo tamaño de bloque ya no puede ser cambiado hasta que la página vuelva a liberarse por completo). -``CONTINUATION``: +``CONTINUATION`` indica que esta página es la continuación de un objeto grande (es decir, que ocupa una o más páginas). Luego se presentan más detalles sobre objetos grandes. @@ -375,28 +375,28 @@ Atributos de bloque ^^^^^^^^^^^^^^^^^^^ Cada bloque tiene asociados varios atributos: -*mark*: +*mark* utilizado en la fase de :ref:`marcado `, indica que un nodo ya fue visitado (serían las celdas *negras* en la :ref:`abstracción tricolor `). -*scan*: +*scan* utilizado también en la fase de :ref:`marcado `, indica que una celda visitada todavía tiene *hijas* sin marcar (serían las celdas *grises* en la :ref:`abstracción tricolor `). -*free*: +*free* indica que el bloque está libre (no está siendo utilizado por ningún objeto *vivo*). Esto es necesario solo por la forma en la que realiza el :ref:`marcado ` y :ref:`barrido ` en el :ref:`algoritmo actual ` (las celdas con el atributo este atributo son tomadas como *basura* aunque estén marcadas con *mark*). -*final*: +*final* indica que el bloque contiene un objeto que tiene un destructor (que debe ser llamado cuando la celda pasa de *viva* a *basura*). -*noscan*: +*noscan* indica que el bloque contiene un objeto que no tiene punteros y por lo tanto no debe ser marcado de forma conservativa (no tiene *hijas*). @@ -951,22 +951,20 @@ El recolector está principalmente contenido en la estructura llamada ``Gcx``. Dicha estructura tiene los siguientes atributos (divididos en categorías para facilitar la comprensión): -**Raíces definidas por el usuario** - - *roots* (*nroots*, *rootdim*): +Raíces definidas por el usuario + *roots* (*nroots*, *rootdim*) arreglo variable de punteros simples que son tomados como raíces provistas por el usuario. - *ranges* (*nranges*, *rangedim*): + *ranges* (*nranges*, *rangedim*) arreglo variable de rangos de memoria que deben ser revisados (de forma conservativa) como raíces provistas por el usuario. Un rango es una estructura con dos punteros: ``pbot`` y ``ptop``. Toda la memoria entre estos dos punteros se toma, palabra por palabra, como una raíz del recolector. -**Estado interno del recolector** - - *anychanges*: +Estado interno del recolector + *anychanges* variable que indica si en la fase de marcado se encontraron nuevas celdas con punteros que deban ser visitados. Otra forma de verlo es como un indicador de si el conjunto de celdas *grises* está vacío luego de @@ -974,36 +972,35 @@ facilitar la comprensión): `). Es análoga a la variable ``more_to_scan`` presentada en :ref:`dgc_algo_mark`. - *inited*: + *inited* indica si el recolector fue inicializado. - *stackBottom*: + *stackBottom* puntero a la base del *stack* (asumiendo que el stack crece hacia arriba). Se utiliza para saber por donde comenzar a visitar el *stack* de forma conservativa, tomándolo con una raíz del recolector. - *Pools* (*pooltable*, *npools*): + *Pools* (*pooltable*, *npools*) arreglo variable de punteros a estructuras ``Pool`` (ver más adelante). Este arreglo se mantiene siempre ordenado de menor a mayor según la dirección de memoria de la primera página que almacena. - *bucket*: + *bucket* listas de libres. Es un arreglo de estructuras ``List`` utilizadas para guardar la listas de libres de todos los tamaños de bloques posibles (ver más adelante). -**Atributos que cambian el comportamiento** - - *noStack*: +Atributos que cambian el comportamiento + *noStack* indica que no debe tomarse al *stack* como raíz del recolector. Esto es muy poco seguro y no debería ser utilizado nunca, salvo casos extremadamente excepcionales. - *log*: + *log* indica si se debe guardar un registro de la actividad del recolector. Es utilizado principalmente para depuración. - *disabled*: + *disabled* indica que no se deben realizar recolecciones implícitamente. Si al tratar de asignar memoria no se puede hallar celdas libres en el *heap* del recolector, se pide más memoria al sistema operativo sin correr una @@ -1012,16 +1009,15 @@ facilitar la comprensión): se pueden tolerar grandes pausas como las que puede provocar el recolector. -**Optimizaciones** - - *p_cache*, *size_cache*: +Optimizaciones + *p_cache*, *size_cache* obtener el tamaño de un bloque dado un puntero es una tarea costosa y común. Para evitarla en casos donde se calcula de forma sucesiva el tamaño del mismo bloque (como puede ocurrir al concatenar arreglos dinámicos) se guarda el último calculado en estas variables a modo de *caché*. - *minAddr*, *maxAddr*: + *minAddr*, *maxAddr* punteros al principio y fin del *heap*. Pueden haber *huecos* entre estos dos punteros que no pertenezcan al *heap* pero siempre se cumple que si un puntero apunta al *heap* debe estar en este rango. Esto es @@ -1048,29 +1044,29 @@ C ``malloc()``, ``realloc()`` y ``free()`` directamente. La estructura ``Pool`` está compuesta por los siguientes atributos (ver figura :vref:`fig:dgc-pool`): -*baseAddr* y *topAddr*: +*baseAddr* y *topAddr* punteros al comienzo y fin de la memoria que almacena todas las páginas del *pool* (*baseAddr* es análogo al atributo *pages* utilizado en las secciones anteriores para mayor claridad). -*mark*, *scan*, *freebits*, *finals*, *noscan*: +*mark*, *scan*, *freebits*, *finals*, *noscan* conjunto de bits (*bitsets*) para almacenar los indicadores descriptos en :ref:`dgc_org` para todos los bloques de todas las páginas del *pool*. *freebits* es análogo a *free* y *finals* a *final* en los atributos descriptos en las secciones anteriores. -*npages*: +*npages* cantidad de páginas que contiene este *pool* (fue nombrado *number_of_pages* en las secciones anteriores para mayor claridad). -*ncommitted*: +*ncommitted* cantidad de páginas *encomendadas* al sistema operativo (*committed* en inglés). Este atributo no se mencionó anteriormente porque el manejo de páginas encomendadas le agrega una complejidad bastante notable al recolector y es solo una optimización para un sistema operativo en particular (Microsoft Windows). -*pagetable*: +*pagetable* arreglo de indicadores de tamaño de bloque de cada página de este *pool*. Los indicadores válidos son ``B_16`` a ``B_2048`` (pasando por los valores posibles de bloque mencionados anteriormente, todos con el prefijo @@ -1144,56 +1140,54 @@ A continuación se resumen las funciones principales, separadas en categorías para facilitar la comprensión. Los siguientes son métodos de la estructura ``Gcx``: -**Inicialización y terminación** - - *initialize()*: +Inicialización y terminación + *initialize()* inicializa las estructuras internas del recolector para que pueda ser utilizado. Esta función la llama la biblioteca *runtime* antes de que el programa comience a correr. - *Dtor()*: + *Dtor()* libera todas las estructuras que utiliza el recolector. -**Manipulación de raíces definidas por el usuario** - - *addRoot(p)*, *removeRoot(p)*, *rootIter(dg)*: +Manipulación de raíces definidas por el usuario + *addRoot(p)*, *removeRoot(p)*, *rootIter(dg)* agrega, remueve e itera sobre las raíces simples definidas por el usuario. - *addRange(pbot, ptop)*, *remove range(pbot)*, *rangeIter(dg)*: + *addRange(pbot, ptop)*, *remove range(pbot)*, *rangeIter(dg)* agrega, remueve e itera sobre los rangos de raíces definidas por el usuario. -**Manipulación de indicadores** - - Cada bloque (*bin* en la terminología de la implementación del recolector) - tiene ciertos indicadores asociados. Algunos de ellos pueden ser - manipulados (indirectamente) por el usuario utilizando estas funciones: - - *getBits(pool, biti)*: +Manipulación de indicadores + *getBits(pool, biti)* obtiene los indicadores especificados para el bloque de índice ``biti`` en el *pool* ``pool``. - *setBits(pool, biti, mask)*: + *setBits(pool, biti, mask)* establece los indicadores especificados en ``mask`` para el bloque de índice ``biti`` en el *pool* ``pool``. - *clrBits(pool, biti, mask)*: + *clrBits(pool, biti, mask)* limpia los indicadores especificados en ``mask`` para el bloque de índice ``biti`` en el *pool* ``pool``. + Cada bloque (*bin* en la terminología de la implementación del recolector) + tiene ciertos indicadores asociados. Algunos de ellos pueden ser + manipulados (indirectamente) por el usuario utilizando las funciones + mencionadas arriba. + El parámetro ``mask`` debe ser una máscara de bits que puede estar compuesta por la conjunción de los siguientes valores: - *FINALIZE*: + *FINALIZE* el objeto almacenado en el bloque tiene un destructor (indicador *finals*). - *NO_SCAN*: + *NO_SCAN* el objeto almacenado en el bloque no contiene punteros (indicador *noscan*). - *NO_MOVE*: + *NO_MOVE* el objeto almacenado en el bloque no debe ser movido [#dgcmove]_. .. [#dgcmove] Si bien el recolector actual no tiene la capacidad de mover @@ -1202,44 +1196,39 @@ para facilitar la comprensión. Los siguientes son métodos de la estructura fijar objetos apuntados desde algún segmento no conservativo (objeto *pinned*). -**Búsquedas** - - *findPool(p)*: +Búsquedas + *findPool(p)* busca el *pool* al que pertenece el objeto apuntado por ``p``. - *findBase(p)*: + *findBase(p)* busca la dirección base (el inicio) del bloque apuntado por ``p`` (``find_block()`` según la sección :ref:`dgc_algo_mark`). - *findSize(p)*: + *findSize(p)* busca el tamaño del bloque apuntado por ``p``. - *getInfo(p)*: + *getInfo(p)* obtiene información sobre el bloque apuntado por ``p``. Dicha información se retorna en una estructura ``BlkInfo`` que contiene los siguientes atributos: ``base`` (dirección del inicio del bloque), ``size`` (tamaño del bloque) y ``attr`` (atributos o indicadores del bloque, los que se pueden obtener con ``getBits()``). - *findBin(size)*: + *findBin(size)* calcula el tamaño de bloque más pequeño que pueda contener un objeto de tamaño ``size`` (``find_block_size()`` según lo visto en :ref:`dgc_algo_alloc`). -**Asignación de memoria** - - Recordar que la ``pooltable`` siempre se mantiene ordenada según la - dirección de la primera página. - - *reserve(size)*: +Asignación de memoria + *reserve(size)* reserva un nuevo *pool* de al menos ``size`` bytes. El algoritmo nunca crea un *pool* con menos de 256 páginas (es decir, 1 MiB). - *minimize()*: + *minimize()* minimiza el uso de la memoria retornando *pools* sin páginas usadas al sistema operativo. - *newPool(n)*: + *newPool(n)* reserva un nuevo *pool* con al menos ``n`` páginas. Junto con ``Pool.initialize()`` es análoga a ``new_pool()``, solo que esta función siempre incrementa el número de páginas a, al menos, 256 páginas (es @@ -1251,7 +1240,7 @@ para facilitar la comprensión. Los siguientes son métodos de la estructura 3 MiB y así sucesivamente hasta 8 MiB. A partir de ahí siempre crea *pools* de 8 MiB o la cantidad pedida, si ésta es mayor. - *Pool.initialize(n_pages)*: + *Pool.initialize(n_pages)* inicializa un nuevo *pool* de memoria. Junto con ``newPool()`` es análoga a ``new_pool()``. Mientras ``newPool()`` es la encargada de calcular la cantidad de páginas y crear el objeto *pool*, esta función @@ -1261,23 +1250,23 @@ para facilitar la comprensión. Los siguientes son métodos de la estructura atributo ``FINALIZE`` a un bloque, se inicializa el conjunto de bits ``finals`` de todo el *pool*. - *allocPage(bin)*: + *allocPage(bin)* asigna a una página libre el tamaño de bloque ``bin`` y enlaza los nuevos bloques libres a la lista de libres correspondiente (análogo a ``assign_page()``). - *allocPages(n)*: + *allocPages(n)* Busca ``n`` cantidad de páginas consecutivas libres (análoga a ``find_pages(n)``). - *malloc(size, bits)*: + *malloc(size, bits)* asigna memoria para un objeto de tamaño ``size`` bytes. Análoga al algoritmo ``new(size, attr)`` presentado, excepto que introduce además un caché para no recalcular el tamaño de bloque necesario si se realizan múltiples asignaciones consecutivas de objetos del mismo tamaño y que la asignación de objetos pequeños no está separada en una función aparte. - *bigAlloc(size)*: + *bigAlloc(size)* asigna un objeto grande (análogo a ``new_big()``). La implementación es mucho más compleja que la presentada en ``new_big()``, pero la semántica es la misma. La única diferencia es que esta función aprovecha que @@ -1286,19 +1275,21 @@ para facilitar la comprensión. Los siguientes son métodos de la estructura el caso en que no se liberaron suficientes páginas para asignar el objeto grande y pasar directamente a crear un nuevo *pool*. - *free(p)*: + *free(p)* libera la memoria apuntada por ``p`` (análoga a ``delete()`` de la sección anterior). -**Recolección** + Recordar que la ``pooltable`` siempre se mantiene ordenada según la + dirección de la primera página. - *mark(pbot, ptop)*: +Recolección + *mark(pbot, ptop)* marca un rango de memoria. Este método es análogo al ``mark()`` presentado en la sección :ref:`dgc_algo_mark` pero marca un rango completo de memoria, lo que permite que sea considerablemente más eficiente. - *fullcollectshell()*: + *fullcollectshell()* guarda los registros en el *stack* y llama a ``fullcollect()``. El algoritmo presentado en :ref:`dgc_algo_mark` es simbólico, ya que si los registros se apilaran en el *stack* dentro de otra función, al salir de @@ -1306,7 +1297,7 @@ para facilitar la comprensión. Los siguientes son métodos de la estructura función ``collect()`` o en una función que luego la llame (como en este caso). - *fullcollect(stackTop)*: + *fullcollect(stackTop)* realiza la recolección de basura. Es análoga a ``collect()`` pero es considerablemente menos modular, todos los pasos se hacen directamente en esta función: marcado del *root set*, marcado iterativo del *heap*, @@ -1676,13 +1667,13 @@ Detalles Finalmente hay varios detalles en la implementación actual que podrían mejorarse: -Listas de libres: +Listas de libres hay 12 listas de libres, como para guardar bloques de tamaño de ``B_16`` a ``B_2048``, ``B_PAGE``, ``B_PAGEPLUS``, ``B_UNCOMMITTED`` y ``B_FREE``; sin embargo solo tienen sentido los bloques de tamaño ``B_16`` a ``B_2048``, por lo que 4 de esas listas no se utilizan. -Conjuntos de bits para indicadores: +Conjuntos de bits para indicadores los indicadores para la fase de marcado y otras propiedades de un bloque son almacenados en conjuntos de bits que almacenan los indicadores de todos los bloques de un *pool*. Si bien se ha mencionado esto como una ventaja, @@ -1697,21 +1688,21 @@ Conjuntos de bits para indicadores: objeto grande; lo que equivaldría al 2560 objetos de 16 bytes desperdiciados en bits inutilizados). -Repetición de código: +Repetición de código Hay algunos fragmentos de código repetidos innecesariamente. Por ejemplo en varios lugares se utilizan arreglos de tamaño variable que se implementan repetidas veces (en general como un puntero al inicio del arreglo más el tamaño actual del arreglo más el tamaño de la memoria total asignada actualmente). Esto es propenso a errores y difícil de mantener. -Uso de señales: +Uso de señales el recolector actual utiliza las señales del sistema operativo ``SIGUSR1`` y ``SIGUSR2`` para pausar y reanudar los hilos respectivamente. Esto puede traer inconvenientes a usuarios que desean utilizar estas señales en sus programas (o peor aún, si interactúan con bibliotecas de C que hacen uso de estas señales) [NGD5821]_. -Marcado iterativo: +Marcado iterativo si bien esto se mencionó como algo bueno del recolector actual, es un compromiso entre tiempo y espacio, y puede ser interesante analizar otros métodos para evitar la recursión que no requieran tantas pasadas sobre el diff --git a/source/gc.rst b/source/gc.rst index d57fa2d..06ed07e 100644 --- a/source/gc.rst +++ b/source/gc.rst @@ -102,7 +102,7 @@ Conceptos básicos Los programas pueden hacer uso principalmente de 4 áreas de memoria: -Registros: +Registros Se trata de la memoria más básica de una computadora. Es el área de memoria en la que puede operar realmente el procesador, es extremadamente escasa y generalmente su uso es administrado por el lenguaje de programación (o @@ -110,7 +110,7 @@ Registros: realizando tareas de muy bajo nivel, un programador nunca manipula los registros explícitamente. -Área de memoria estática: +Área de memoria estática Es la forma de memoria más simple que un programador utiliza explícitamente. En general las variables globales se almacenan en este área, que es parte inherente del programa y está disponible durante toda su @@ -120,7 +120,7 @@ Registros: compilación**. Los primeros lenguajes de programación solo contaban con este tipo de memoria (además de los registros del procesador). -*Stack* (pila): +*Stack* (pila) Los primeros lenguajes de programación que hicieron uso de una pila aparecieron en el año 1958 (Algol-58 y Atlas Autocode) y fueron los primeros en introducir estructura de bloques, almacenando las variables @@ -138,7 +138,7 @@ Registros: a otra cosa, como al nodo de una lista o a un objeto en el sentido de programación orientada a objetos). -*Heap*: +*Heap* A diferencia del *stack*, el *heap* provee un área de memoria que puede ser obtenida dinámicamente pero sin limitaciones de orden. Es el tipo de memoria más flexible y por lo tanto el más complejo de administrar; razón @@ -212,7 +212,7 @@ fueron visitados componen el *live set*; el resto de los vértices son Más formalmente, Definimos: -*Camino*: +*Camino* secuencia de vértices tal que cada uno de los vértices tiene una arista al próximo vértice en la secuencia. Todo camino finito tiene un *vértice inicial* y un *vértice final* (llamados en conjunto *vértices terminales*). @@ -225,7 +225,7 @@ Más formalmente, Definimos: \exists (v_i \to v_{i+1}) \in A \right\rbrace -*Conexión*: +*Conexión* decimos que :math:`M` está *conectado* a :math:`N` si y sólo si existe un camino de :math:`M` a :math:`N`. @@ -233,7 +233,7 @@ Más formalmente, Definimos: M \mapsto N \Longleftrightarrow \exists \underset{M \to N}{C} \in G -*Live set*: +*Live set* el conjunto de celdas *vivas* está dado por todos los vértices (:math:`v`) del grafo para los cuales existe una raíz en el *root set* que esté conectada a él. @@ -244,7 +244,7 @@ Más formalmente, Definimos: \left( \exists r \in Root \thickspace set \big/ r \mapsto v \right) \right\rbrace -*Basura*: +*Basura* la basura, o celdas *muertas*, quedan determinadas entonces por todas las celdas del *heap* que no son parte del *live set*. @@ -663,7 +663,7 @@ recolectores a lo largo de este documento. Servicios utilizados por el recolector son los siguientes: -:math:`alloc() \to cell`: +:math:`alloc() \to cell` obtiene una nueva celda de memoria. El mecanismo por el cual se obtiene la celda es indistinto para esta sección, puede ser de una lista libre, puede ser de un administrador de memoria de más bajo nivel provisto por el @@ -676,16 +676,16 @@ Servicios utilizados por el recolector son los siguientes: contrario) que las celdas son de tamaño fijo. Esta restricción normalmente puede ser fácilmente relajada (en los recolectores que la tienen). -:math:`free(cell)`: +:math:`free(cell)` libera una celda que ya no va a ser utilizada. La celda liberada debe haber sido obtenida mediante ``alloc()``. Y los servicios básicos proporcionados por el recolector son los siguientes: -:math:`new() \to cell`: +:math:`new() \to cell` obtiene una celda de memoria para ser utilizada por el programa. -:math:`update(ref, cell)`: +:math:`update(ref, cell)` notifica al recolector que la referencia :math:`ref` ahora apunta a :math:`cell`. Visto más formalmente, sería análogo a decir que hubo un cambio en la conectividad del grafo: la arista :math:`src \to old` cambia @@ -695,7 +695,7 @@ Y los servicios básicos proporcionados por el recolector son los siguientes: :math:`cell` es ``null``, sería análogo a informar que se elimina la arista :math:`src \to old`. -:math:`del(cell)`: +:math:`del(cell)` este servicio, según el algoritmo, puede ser utilizado para informar un cambio en la conectividad del grafo, la eliminación de una arista (análogo a :math:`update(ref, null)` pero sin proporcionar información sobre la @@ -705,7 +705,7 @@ Y los servicios básicos proporcionados por el recolector son los siguientes: a eliminar el conjunto de aristas :math:`\big\lbrace (v, w) \in A , v \in Live \thickspace set , w \in Live \thickspace set \big/ w = cell`. -:math:`collect()`: +:math:`collect()` indica al recolector que debe hacer un análisis del grafo de conectividad en busca de *basura*. Generalmente este servicio es invocado por el propio recolector cuando no hay más celdas reciclables. diff --git a/source/glosario.rst b/source/glosario.rst index db0276a..9dbfe53 100644 --- a/source/glosario.rst +++ b/source/glosario.rst @@ -5,24 +5,24 @@ Glosario .. glossary:: :sorted: - *mutator*: + *mutator* parte del programa que realiza cambios al grafo de conectividad. - recolector: + recolector parte del programa que recupera celdas *muertas* (no realiza cambios en el grafo de conectividad). - recolector *híbrido*: + recolector *híbrido* recolector que emplea distintas técnicas de recolección dependiendo de distintas características de las celdas (por ejemplo cuantas recolecciones lleva sin ser recolectado, el tamaño de celda, etc.). - grafo de conectividad: + grafo de conectividad grafo conformado por la memoria del *heap*. Los vértices son las celdas de memoria y las aristas las referencias (o punteros) que tiene una celda apuntando a otras. Ver :ref:`gc_intro_basics`. - abstracción bicolor: + abstracción bicolor método para marcar todas las celdas de un grafo que sea accesibles de forma transitiva a partir de una o más raíces que consiste en *pintar* todas las celdas de blanco inicialmente y luego, a medida que son @@ -30,7 +30,7 @@ Glosario accesibles están pintadas de negro y el resto de blanco. Ver :ref:`gc_intro_mark`. - abstracción tricolor: + abstracción tricolor método para marcar todas las celdas de un grafo que sea accesibles de forma transitiva a partir de una o más raíces que consiste en *pintar* todas las celdas de blanco inicialmente y luego, a medida que son @@ -39,182 +39,182 @@ Glosario accesibles están pintadas de negro y el resto de blanco. Ver :ref:`gc_intro_tricolor`. - celda: + celda porción contigua de memoria destinada a almacenar un objeto o estructura de dato particular. - celda *blanca*: + celda *blanca* en la abstracción bicolor y tricolor, son celdas que no fueron aún visitadas por la fase de marcado. - celda *negra*: + celda *negra* en la abstracción bicolor y tricolor, son celdas que ya fueron visitadas por completo (es decir, incluyendo sus celdas *hijas*) por la fase de marcado. - celda *gris*: + celda *gris* en la abstracción tricolor, son celdas que ya fueron visitadas por la fase de marcado pero deben ser visitadas nuevamente (porque sus *hijas* no fueron visitadas por completo todavía o porque hubo algún cambio en la celda). - celda *hija*: + celda *hija* celda para la cual existe una referencia desde la celda actual. Se dice que *H* es *hija* de *P* si *P* contiene una referencia a *H*. - celda *jóven*: + celda *jóven* celda que no lleva ninguna (o muy pocas) recolecciones sin ser recolectada. - celda *vieja*: + celda *vieja* celda que lleva varias recolecciones sin ser recolectada. - celda *viva*: + celda *viva* celda de memoria que puede ser accedida transitivamente a través del *root set*. - celda *muerta*: + celda *muerta* celda de memoria que no puede ser accedida transitivamente a través del *root set*. - *basura*: + *basura* dependiendo del contexto, se refiere a una celda *muerta*, un conjunto de celdas *muertas* o al conjunto completo de celdas *muertas*. - *root set*: + *root set* conjunto de celdas de memoria que sirven como punto de partida para recorrer el grafo de conectividad. En general se compone de memoria estática, registros y el *stack*. - *live set*: + *live set* conjunto de todas las celdas *vivas*. - palabra: + palabra tamaño de dato característico de un procesador que permite almacenar una dirección de memoria. Generalmente este tamaño coincide con el tamaño de dato que el procesador puede manipular de forma más eficiente. - registro: + registro memoria muy veloz del procesador que por lo general tiene el tamaño de una palabra. En general son muy escasos y es donde los procesadores hacen realmente los cálculos. - *heap*: + *heap* área de memoria que en la cual se asigna y liberan celdas dinámicamente (durante la ejecución del programa). - *stack*: + *stack* área de memoria organizada en forma de pila donde se almacenan típicamente las variables locales, parámetros, valor de retorno y dirección de retorno de las subrutinas - *dangling pointer*: + *dangling pointer* (o *puntero colgante* en castellano) puntero que almacena una dirección de memoria inválida. - localidad de referencia: + localidad de referencia medida en que los accesos sucesivos de memoria cercana espacialmente son cercanos también en el tiempo. Por ejemplo, un programa que lee todos los elementos de una matriz contigua de una vez o que utiliza la misma variable repetidamente tiene buena localidad referencia. - *working set*: + *working set* conjunto de celdas con la que trabaja el programa de forma intensiva durante un período considerable de tiempo. - *hit rate*: + *hit rate* frecuencia con la que el caché puede responder con éxito. - *cache*: + *cache* memoria pequeña (por ser típicamente muy costosa) pero muy veloz. - memoria estática: + memoria estática memoria fija destinada a un programa. Es fija en el sentido en que no varía su tamaño ni puede asignarse o liberarse durante la ejecución del programa. - referencia débil: + referencia débil referencia que no es tomada en cuenta en el grafo de conectividad (es decir, si un objeto es solamente alcanzable a través de una referencia débil, puede ser reciclado por el recolector). - *weak reference*: + *weak reference* ver referencia débil. - ciclo: + ciclo un conjunto de celdas que están referenciadas entre sí de forma tal que siempre se puede llegar de una celda a sí misma a través de las referencias. - *low level allocator*: + *low level allocator* administrador de memoria de bajo nivel que obtiene la memoria del sistema operativo y la provee al recolector (o al *mutator* directamente). - *fragmentación*: + *fragmentación* incapacidad de usar memoria debido a la disposición de memoria actualmente en uso, que deja la memoria libre dividida en bloques demasiado pequeños. - *multi-core*: + *multi-core* arquitectura que combina dos o más núcleos (*cores*) independientes que trabajan a la misma frecuencia, pero dentro de un solo circuito integrado o procesador. - *pinning*: + *pinning* técnica que consiste en marcar una celda como inmóvil. Generalmente se utiliza en recolectores semi-conservativos con movimiento para no mover celdas que son alcanzadas desde palabras para las que no se tiene información de tipos. - puntero *interior*: + puntero *interior* puntero que en vez de apuntar al inicio de una celda, apuntan a una dirección arbitraria dentro de ella. - *two level allocators*: + *two level allocators* administrador de memoria que utiliza dos niveles para organizar las celdas de memoria; obtiene del sistema operativo páginas completas y éstas a su vez de dividen en bloques que son utilizados para almacenar las celdas. - página: + página unidad mínima de memoria que asigna el sistema operativo a un programa (típicamente el tamaño de página es de 4096 bytes). - dirección: + dirección una dirección de memoria es la especificación de su ubicación en memoria. Típicamente se representan como enteros sin signo y ocupan una palabra. - *address space*: + *address space* conjunto de posibles direcciones de memoria asignada a un programa. Puede ser un conjunto no contiguo o espaciado. - *lock*: + *lock* también conocido como *mutex* (abreviación de *exclusión mutua* en inglés), es un objeto de sincronización que permite serializar la ejecución de múltiples hilos. - *best-fit*: + *best-fit* búsqueda para encontrar la región de memoria contigua libre que mejor se ajuste al tamaño de un objeto (es decir, la región más pequeña lo suficientemente grande como para almacenarlo). - *first-fit*: + *first-fit* búsqueda para encontrar la primera región de memoria contigua libre donde quepa un objeto (es decir, la primera región lo suficientemente grande como para almacenar el objeto a asignar). - *stack overflow*: + *stack overflow* ver *desbordamiento de pila*. - desbordamiento de pila: + desbordamiento de pila agotamiento del *stack*. - *bitset*: + *bitset* ver conjunto de bits. - conjunto de bits: + conjunto de bits estructura de datos que sirve para almacenar un conjunto de indicadores de forma eficiente. Generalmente se implementa utilizando una porción de memoria donde cada bit es un indicador; si el bit está en 0 el indicador @@ -222,131 +222,131 @@ Glosario manipulación de los bits (individuales y en conjunto) en general se realiza de forma eficiente utilizando máscaras. - *system programming*: + *system programming* se refiere a programación de bajo nivel. En general involucra manipulación de punteros, acceso directo al lenguaje de máquina y por consiguiente al *hardware*. - *parsing*: + *parsing* análisis sintáctico de un lenguaje estructurado. - *context-free grammar*: + *context-free grammar* gramática que no depende del contexto (es decir, de información semántica). - *templates*: + *templates* técnica para construir algoritmos genéricos incluyendo parámetros como tipos o valores. - *string*: + *string* secuencia lineal de caracteres utilizada normalmente en los lenguajes de programación para representar texto (aunque pueden ser utilizados para representar una secuencia lineal de bytes de cualquier tipo también). - *mixin*: + *mixin* en D_ se refiere a un fragmento de código (M) que puede incluirse dentro de otro (O) como si M hubiera sido escrito directamente dentro de O. En general se utiliza para suplantar la herencia múltiple pero tiene muchos otros usos. - función *pura*: + función *pura* función que no tiene efectos secundarios. Una función pura ejecutada con los mismo parámetros siempre devuelve el mismo resultado. - *runtime*: + *runtime* biblioteca base de un lenguaje que provee los servicios básicos (como creación de objetos, manejo de hilos u otras construcciones que ofrezca el lenguaje). - *tipado* estático: + *tipado* estático verificación de tipos en tiempo de compilación. - *tipado* dinámico: + *tipado* dinámico verificación de tipos en tiempo de ejecución. - verificación de tipos: + verificación de tipos forma en la que un sistema de tipos asigna tipos y verifica sus interacciones. - sistema de tipos: + sistema de tipos forma en que un lenguaje de programación clasifica valores y expresiones en tipos, como los manipula y como interactúan éstos entre sí. - conversión *covariante*: + conversión *covariante* conversión de tipos que preserva el orden de los tipos de más específicos a más genéricos. - *type-safe*: + *type-safe* operación que no compromete ni subvierte la verificación de tipos. - *excepción*: + *excepción* construcción de un lenguaje de programación para manejar la presencia de situaciones anormales (en general errores) cambiando el flujo de ejecución del programa. - *exception-safe*: + *exception-safe* propiedad de un programa que ante un error en tiempo de ejecución manifestado como una *excepción* no provoca efectos indeseados (como pérdida de memoria, corrupción de datos o salida inválida). - *thread-safe*: + *thread-safe* propiedad de una función o fragmento de código que permite que corra concurrentemente en dos o más hilos de ejecución paralelos sin provocar efectos indeseados (como pérdida de memoria, corrupción de datos o salida inválida). - *CTFE*: + *CTFE* abreviatura en inglés de *Compile-Time Function Execution*, es la capacidad de un lenguaje de programación de ejecutar una función en tiempo de compilación en vez de tiempo de ejecución. - *ABI*: + *ABI* abreviatura en inglés de *Application Binary Interface*, es la interfaz de bajo nivel entre un programa y el sistema operativo u otro programa. - arreglo: + arreglo disposición de celdas de igual tamaño de forma consecutiva en la memoria de manera que puedan ser fácilmente indizadas. - *overhead*: + *overhead* cualquier combinación de exceso directo o indirecto de tiempo de computación, memoria, ancho de banda u otro recurso que sea requerido para cumplir un objetivo particular. - *pattern matching*: + *pattern matching* acto de verificar la presencia de un constituyente sintáctico de un patrón dado. - *activation record*: + *activation record* ver *stack frame*. - *stack frame*: + *stack frame* estructura de datos dependiente de la arquitectura que contiene información del estado de una función, incluyendo, por ejemplo, sus variables locales, parámetros y dirección de retorno. - *delegado*: + *delegado* es una estructura simple que modela una función acompañada de un contexto. En general se utiliza para representar un puntero a una función miembro de un objeto en particular o a una función anidada (donde el contexto es el *stack frame* de la función que la contiene). - ciudadano de primera clase: + ciudadano de primera clase tipo soportado por completo por el lenguaje (por ejemplo disponen de expresiones literales anónimas, pueden ser almacenados en variables y estructuras de datos, tienen una identidad intrínseca, etc.). - semántica de valor: + semántica de valor propiedad de los tipos son tratado como si fuera un valor concreto. En general se pasa por valor y se hacen copias a menos que se utilice explícitamente un puntero. - semántica de referencia: + semántica de referencia propiedad de los tipos que son tratados como si fueran un puntero. Nunca se hacen copias del objeto, siempre se pasa por referencia implícitamente. - *slicing*: + *slicing* problema que surge cuando los objetos polimórficos tienen semántica de valor, consiste en pasar una clase derivada a una función que acepta una clase base por valor como parámetro. Al realizarse la copia, se utiliza @@ -354,158 +354,158 @@ Glosario de la clase derivada, y la información de tipos en tiempo de ejecución (*RTTI*). - *RTTI*: + *RTTI* abreviatura del inglés *Run-Time Type Identification*, es la información de tipos disponible en tiempo de ejecución. - *DbC*: + *DbC* ver diseño por contrato (del inglés *Design by Contract*). - *diseño por contrato*: + *diseño por contrato* técnica de diseño de software que consiste en especificar formalmente, de forma precisa y verificable, la interfaz entre componentes de software. - *RAII*: + *RAII* técnica que consiste en reservar recursos por medio de la construcción de un objeto y liberarlos cuando éste se libera (del inglés *Resourse Adquisition Is Initialization*). - *front-end*: + *front-end* parte del compilador encargada de hacer el análisis léxico, sintáctico y semántico del código fuente, generando una representación intermedia que luego el *back-end* convierte a código de máquina. - *back-end*: + *back-end* parte del compilador encargada de convertir la representación intermedia generada por el *front-end* a código de máquina. - finalización: + finalización referente a la acción de llamar a una función miembro de un objeto, generalmente llamada destructor, cuando éste deja de ser utilizado. - determinístico: + determinístico algoritmo o proceso que se comporta de forma predecible (dada una cierta entrada siempre produce el mismo resultado y los pasos realizados son exactamente los mismo, pasando por la misma secuencia de estados). - fase de marcado: + fase de marcado primera fase del algoritmo *marcado y barrido* (entre otros). Ver :ref:`gc_intro_mark` y :ref:`gc_mark_sweep`. - fase de barrido: + fase de barrido segunda fase del algoritmo *marcado y barrido*. Ver :ref:`gc_mark_sweep`. - conteo de referencias: + conteo de referencias uno de los tres principales algoritmos clásicos de recolección de basura. Ver :ref:`gc_rc`. - marcado y barrido: + marcado y barrido uno de los tres principales algoritmos clásicos de recolección de basura. Ver :ref:`gc_mark_sweep`. - copia de semi-espacio: + copia de semi-espacio uno de los tres principales algoritmos clásicos de recolección de basura. Ver :ref:`gc_copy`. - *semi-space*: + *semi-space* nombre alternativo para el algoritmo *copia de semi-espacios*. Ver :ref:`gc_copy`. - *two-space*: + *two-space* nombre alternativo para el algoritmo *copia de semi-espacios*. Ver :ref:`gc_copy`. - *copying collector*: + *copying collector* nombre alternativo para el algoritmo *copia de semi-espacios*, aunque puede referirse también a una familia más general de algoritmos con movimiento de celdas. Ver :ref:`gc_copy` y :ref:`gc_moving`. - *fromspace*: + *fromspace* uno de los dos semi-espacios del algoritmo *copia de semi-espacios*. Ver :ref:`gc_copy`. - *tospace*: + *tospace* uno de los dos semi-espacios del algoritmo *copia de semi-espacios*. Ver :ref:`gc_copy`. - *forwarding address*: + *forwarding address* dirección de memoria de re-dirección utilizada para localizar la nueva ubicación de una celda en algoritmos de recolección con movimiento. Ver :ref:`gc_copy`. - recolección directa: + recolección directa recolección en la cual el compilador o lenguaje instrumenta al *mutator* de forma tal que la información sobre el grafo de conectividad se mantenga activamente cada vez que hay un cambio en él. Ver :ref:`gc_direct`. - recolección indirecta: + recolección indirecta recolección que, generalmente, no interfiere con el *mutator* en cada actualización del grafo de conectividad. Ver :ref:`gc_direct`. - recolección incremental: + recolección incremental recolección que se realiza de forma intercalada con el *mutator*. Ver :ref:`gc_inc`. - recolección concurrente: + recolección concurrente recolección que puede correr en paralelo con el *mutator*. Ver :ref:`gc_concurrent`. - recolección paralela: + recolección paralela recolección que puede correr en paralelo en varios hilos. Ver :ref:`gc_concurrent`. - recolección *stop-the-world*: + recolección *stop-the-world* recolección que detiene todos los hilos del *mutator*. Ver :ref:`gc_concurrent`. - *stop-the-world*: + *stop-the-world* ver *recolección stop-the-world*. - lista de libres: + lista de libres forma de organizar el *heap* en la cual se asigna una nueva celda obteniéndola de una lista de celdas libres. Ver :ref:`gc_free_list`. - *pointer bump allocation*: + *pointer bump allocation* forma de organizar el *heap* en la cual se asigna una nueva celda incrementando un puntero. Ver :ref:`gc_free_list`. - recolección con movimiento de celdas: + recolección con movimiento de celdas recolección en la cual una celda de memoria puede ser movida a otra ubicación en el *heap*. Ver :ref:`gc_moving`. - recolección conservativa: + recolección conservativa recolección que no tiene información de tipos y trata cada palabra del *root set* o *heap* como un posible puntero. Ver :ref:`gc_conserv`. - recolección precisa: + recolección precisa recolección que tiene información de tipos completa y puede determinar exactamente que palabras son punteros y cuales no. Ver :ref:`gc_conserv`. - recolección semi-precisa: + recolección semi-precisa recolección que tiene información de tipos parcial y puede determinar para algunas palabras si son punteros o no, y para otras las trata como punteros potenciales. Ver :ref:`gc_conserv`. - *falso positivo*: + *falso positivo* palabra que es tratada como un potencial puntero cuyo valor almacenado coincide con una dirección válida dentro del *heap* pero que en realidad no es un puntero. - recolección por particiones: + recolección por particiones recolección en la que se divide el *heap* en particiones con el objetivo de recolectar la partición con mayor concentración de *basura*. Ver :ref:`gc_part`. - recolección generacional: + recolección generacional caso particular de *recolección por particiones* en el cual las particiones se realizan utilizando la cantidad de recolecciones que *sobrevive* una celda. Ver :ref:`gc_part`. - *benchmark*: + *benchmark* banco de pruebas utilizado para medir y comparar el rendimiento de un programa, algoritmo o proceso en general.