From 3574dc3e457331aed8212c161d539ad5f69665d5 Mon Sep 17 00:00:00 2001 From: Leandro Lucarella Date: Wed, 10 Jun 2009 12:37:11 -0300 Subject: [PATCH 1/1] Reemplazar verbo alocar por asignar Alocar en castellano significa "causar locura" y no es eso precisamente a lo que nos referimos =) --- source/d.rst | 4 ++-- source/gc.rst | 39 ++++++++++++++++++++------------------- 2 files changed, 22 insertions(+), 21 deletions(-) diff --git a/source/d.rst b/source/d.rst index 3fd0ce8..f3f90db 100644 --- a/source/d.rst +++ b/source/d.rst @@ -456,7 +456,7 @@ Compatibilidad con C: printf("3 + 5 == %d\n", 3 + 5); // llama al printf de C Manejo de memoria explícito: - permite alocar estructuras en el *stack* o en el *heap*, haciendo uso de + 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*: @@ -464,7 +464,7 @@ Objetos y arreglos *livianos*: agrupamiento de variables análogo al ``struct`` de C, sin tabla virtual ni otro tipo de *overhead*. Los arreglos *livianos* son arreglos estáticos como en C, cuyo tamaño es fijo, también sin ningún tipo de *overhead* como - C. Además puede alocarse un arreglo dinámicamente usando ``malloc()`` + C. Además puede asignarse un arreglo dinámicamente usando ``malloc()`` y utilizar el operador ``[]`` para accederlo. Esto también permite interoperar con C, ya que pueden definirse ``structs`` diff --git a/source/gc.rst b/source/gc.rst index d1dd322..3141526 100644 --- a/source/gc.rst +++ b/source/gc.rst @@ -53,7 +53,7 @@ frecuente de problemas de seguridad [BEZO06]_. apuntado no es el mismo tipo o porque la memoria ya ha sido liberada. Al ser desreferenciado, los resultados son impredecibles, el programa podría abortarse por una violación de segmento o podrían pasar peores cosas si el - área de memoria fue realocada para almacenar otro objeto. + área de memoria fue re-asignada para almacenar otro objeto. La recolección de basura nació junto a Lisp_ a finales de 1950 y en los siguientes años estuvo asociada principalmente a lenguajes funcionales, pero @@ -127,11 +127,11 @@ Registros: utilizar recursividad y tener un esquema simple de memoria dinámica. Sin embargo este esquema es muy limitado porque el orden de reserva y liberación de memoria tiene que estar bien establecido. Una celda - [#gccelda]_ alocada antes que otra nunca puede ser liberada antes que + [#gccelda]_ asignada antes que otra nunca puede ser liberada antes que aquella. .. [#gccelda] En general en la literatura se nombra a una porción de - memoria alocada individualmente *celda*, *nodo* u *objeto* + memoria asignada individualmente *celda*, *nodo* u *objeto* indistintamente. En este trabajo se utilizará la misma nomenclatura (haciendo mención explícita cuando alguno de estos términos se refiera a otra cosa, como al nodo de una lista o a un objeto en el sentido de @@ -1683,10 +1683,11 @@ Copia de semi-espacio Este algoritmo consiste en hacer una partición del *heap* en 2 mitades o *semi-espacios*, llamados usualmente *Fromspace* y *Tospace*. El primero se -utiliza para alocar nuevas celdas de forma lineal, asumiendo un *heap* +utiliza para asignar nuevas celdas de forma lineal, asumiendo un *heap* contiguo, incrementando un puntero (ver figura :vref:`fig:gc-copy`). Esto se conoce como *pointer bump allocation* y es, probablemente, la forma más -eficiente de alocar memoria (tan eficiente como alocar memoria en el *stack*). +eficiente de asignar memoria (tan eficiente como asignar memoria en el +*stack*). .. fig:: fig:gc-copy @@ -1719,9 +1720,9 @@ La segunda mitad (*Tospace*) permanece inutilizada hasta que se agota el espacio en el *Fromspace*; en ese momento comienza el proceso de recolección de basura que consiste en recorrer el grafo de conectividad, copiando las celdas *vivas* del *Fromspace* al *Tospace* de manera contigua, como si -estuvieran alocando por primera vez. Como la posición en memoria de las celdas -cambia al ser movidas, es necesario actualizar la dirección de memoria de -todas las celdas *vivas*. Para esto se almacena una dirección de memoria de +estuvieran asignando por primera vez. Como la posición en memoria de las +celdas cambia al ser movidas, es necesario actualizar la dirección de memoria +de todas las celdas *vivas*. Para esto se almacena una dirección de memoria de redirección, *forwarding address*, en las celdas que mueven. La *forwarding address* sirve a su vez de marca, para no recorrer una celda dos veces (como se explica en :ref:`gc_intro_mark`). Cuando se encuentra una celda que ya fue @@ -1735,7 +1736,7 @@ viejo *Fromspace* es *basura* por definición, por lo que se convierte el A continuación se presenta una implementación sencilla de los servicios provistos por este tipo de recolectores. Cabe destacar que este tipo de recolectores deben estar íntimamente relacionados con el *low level -allocator*, ya que la organización del *heap* y la forma de alocar memoria es +allocator*, ya que la organización del *heap* y la forma de asignar memoria es parte fundamental de este algoritmo. Se asume que ya hay dos áreas de memoria del mismo tamaño destinadas al *Fromspace* y *Tospace*, y la existencia de 4 variables: ``fromspace`` (que apunta a la base del *Fromspace*), ``tospace`` @@ -1744,7 +1745,7 @@ un semi-espacio) y ``free`` (que apunta al lugar del *Fromspace* donde comienza la memoria libre). También vale aclarar que este algoritmo soporta inherentemente celdas de tamaño variable, por lo que los servicios ``alloc()`` y ``new()`` [#gccopynew]_ reciben como parámetro el tamaño de la celda -a alocar:: +a asignar:: function alloc(size) is if free + size > fromspace + spacesize @@ -2109,7 +2110,7 @@ con el *mutator* en cada actualización del grafo de conectividad (exceptuando algunos :ref:`recolectores incrementales ` que a veces necesitan instrumentar el *mutator* pero no para mantener el estado del grafo de conectividad completo). La recolección se dispara usualmente cuando el -*mutator* requiere alocar memoria pero no hay más memoria libre conocida +*mutator* requiere asignar memoria pero no hay más memoria libre conocida disponible y el recolector se encarga de generar la información de conectividad desde cero para determinar qué celdas son *basura*. @@ -2140,7 +2141,7 @@ De los `algoritmos clásicos`_ el único que es incremental en su forma más básica es el :ref:`conteo de referencias `. Otros recolectores pueden hacerse incrementales de diversas maneras, pero en general consta de hacer parte del trabajo de escanear el grafo de conectividad cada vez que el -*mutator* aloca memoria. En general para hacer esto es también necesario +*mutator* asigna memoria. En general para hacer esto es también necesario instrumentar al *mutator* de forma tal que informe al recolector cada vez que cambia el grafo de conectividad, para que éste pueda marcar al sub-grafo afectado por el cambio como *desactualizado* y así re-escanearlo nuevamente en @@ -2286,15 +2287,15 @@ en una lista de libres. Al solicitarse una nueva celda simplemente se la desenlaza de la lista de libres. Por otro lado, cuando el recolector detecta una celda *muerta*, la vuelve a enlazar en la lista de libres. Este es un esquema simple pero con limitaciones, entre las principales, el costo de -alocar puede ser alto si hay muchos tamaños distintos de celda y soportar +asignar puede ser alto si hay muchos tamaños distintos de celda y soportar tamaño de celda variable puede ser complejo o acarrear muchas otras ineficiencias. :ref:`gc_mark_sweep` en general usa este esquema, al igual que :ref:`gc_rc`. Otro forma de organizar el *heap* es utilizándolo como una especie de *stack* -en el cual para alocar simplemente se incrementa un puntero. Este esquema es +en el cual para asignar simplemente se incrementa un puntero. Este esquema es simple y eficiente, si el recolector puede mover celdas (ver -:ref:`gc_moving`); de otra manera alocar puede ser muy costoso si hay que +:ref:`gc_moving`); de otra manera asignar puede ser muy costoso si hay que buscar un *hueco* en el heap (es decir, deja de reducirse a incrementar un puntero). El clásico ejemplo de esta familia es :ref:`gc_copy`. @@ -2303,9 +2304,9 @@ recolectores basados en *regiones*, que se encuentran en un punto intermedio. Dentro de una región se utiliza un esquema de *pointer bump allocation* pero las regiones en sí se administran como una lista de libres (como por ejemplo [BLAC08]_). Otra variación (más común) de este esquema son los *two level -allocators* que alocan páginas completas (similar a las regiones) y dentro de -cada página se alocan las celdas. Ambas, páginas y celdas, se administran como -listas de libres (ejemplos que utilizan este esquema son [BOEHWD]_ y el +allocators* que asignan páginas completas (similar a las regiones) y dentro de +cada página se asignan las celdas. Ambas, páginas y celdas, se administran +como listas de libres (ejemplos que utilizan este esquema son [BOEHWD]_ y el :ref:`recolector actual de D `). @@ -2319,7 +2320,7 @@ Otra característica muy importante del recolector de basura es si mueve las celdas o no. En general el movimiento de celdas viene de la mano del esquema de :ref:`pointer bump allocation `, ya que *compacta* todas las celdas *vivas* al comienzo del *heap* luego de una recolección, permitiendo -este esquema para alocar nuevas celdas, pero puede utilizarse en esquemas +este esquema para asignar nuevas celdas, pero puede utilizarse en esquemas híbridos como recolectores basados en *regiones* (por ejemplo [BLAC08]_). Además los recolectores con movimiento de celdas deben ser :ref:`precisos -- 2.43.0