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).
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.
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``.
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
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.
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
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
}
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.
}
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
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
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
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.
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)``.
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
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.
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
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
}
);
-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*
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
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
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
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.
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
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
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.
}
-Propiedades (*properties*):
+Propiedades (*properties*)
en D_ se refiere a funciones miembro que pueden ser tratadas
sintácticamente como campos de esa clase/estructura.
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
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.
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
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)
// 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
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()``.
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
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
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*,
// 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.
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
^^^^^^^^^^^^^^^^^^^
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).
``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.
^^^^^^^^^^^^^^^^^^^
Cada bloque tiene asociados varios atributos:
-*mark*:
+*mark*
utilizado en la fase de :ref:`marcado <dgc_algo_mark>`, indica que un nodo
ya fue visitado (serían las celdas *negras* en la :ref:`abstracción
tricolor <gc_intro_tricolor>`).
-*scan*:
+*scan*
utilizado también en la fase de :ref:`marcado <dgc_algo_mark>`, indica que
una celda visitada todavía tiene *hijas* sin marcar (serían las celdas
*grises* en la :ref:`abstracción tricolor <gc_intro_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 <dgc_algo_mark>` y :ref:`barrido <dgc_algo_sweep>` en el
:ref:`algoritmo actual <dgc_algo>` (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*).
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
<gc_intro_tricolor>`). 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
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
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
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
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
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
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
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
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*,
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,
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
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
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
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
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
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*).
\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`.
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.
\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*.
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
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
: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
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.
.. 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
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
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
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
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.
projects / z.facultad / 75.00 / informe.git / commitdiff