From 22cb44a8463f90a10ca59340382c1d104b2cda74 Mon Sep 17 00:00:00 2001 From: Leandro Lucarella Date: Fri, 19 Jun 2009 22:30:53 -0300 Subject: [PATCH] =?utf8?q?Corregir=20indentaci=C3=B3n?= MIME-Version: 1.0 Content-Type: text/plain; charset=utf8 Content-Transfer-Encoding: 8bit --- source/dgc.rst | 34 +++++++++++++++++----------------- source/gc.rst | 6 +++--- 2 files changed, 20 insertions(+), 20 deletions(-) diff --git a/source/dgc.rst b/source/dgc.rst index a457444..11d0c0c 100644 --- a/source/dgc.rst +++ b/source/dgc.rst @@ -1678,25 +1678,25 @@ Finalmente hay varios detalles en la implementación actual que podrían mejorarse: 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. + 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: - 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, hay - lugar todavía como para algunas mejoras. Como un *pool* tiene páginas con - distintos tamaños de bloque, se reserva una cantidad de bits igual a la - mayor cantidad posible de bloques que puede haber en el *pool*; es decir, se - reserva 1 bit por cada 16 bytes del *pool*. Para un *pool* de 1 MiB (tamaño - mínimo), teniendo en cuenta que se utilizan 5 conjuntos de bits (``mark``, - ``scan``, ``finals``, ``freebits`` y ``noscan``), se utilizan 40 KiB de - memoria para conjuntos de bits (un 4% de *desperdicio* si, por ejemplo, ese - *pool* estuviera destinado por completo a albergar un solo objeto grande; lo - que equivaldría al 2560 objetos de 16 bytes desperdiciados en bits - inutilizados). + 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, + hay lugar todavía como para algunas mejoras. Como un *pool* tiene páginas + con distintos tamaños de bloque, se reserva una cantidad de bits igual a la + mayor cantidad posible de bloques que puede haber en el *pool*; es decir, + se reserva 1 bit por cada 16 bytes del *pool*. Para un *pool* de 1 MiB + (tamaño mínimo), teniendo en cuenta que se utilizan 5 conjuntos de bits + (``mark``, ``scan``, ``finals``, ``freebits`` y ``noscan``), se utilizan 40 + KiB de memoria para conjuntos de bits (un 4% de *desperdicio* si, por + ejemplo, ese *pool* estuviera destinado por completo a albergar un solo + objeto grande; lo que equivaldría al 2560 objetos de 16 bytes + desperdiciados en bits inutilizados). Repetición de código: Hay algunos fragmentos de código repetidos inecesariamente. Por ejemplo en diff --git a/source/gc.rst b/source/gc.rst index 6abc764..a221059 100644 --- a/source/gc.rst +++ b/source/gc.rst @@ -183,9 +183,9 @@ lenguajes de programación que requieran un recolector de basura conservativo. Por último, siendo que el recolector de basura es parte del programa de forma indirecta, es común ver en la literatura que se direfencia entre 2 partes del programa, el recolector de basura y el programa en sí. Dado que - para el recolector de basura, lo único que interesa conocer del programa en - sí son los cambios al grafo de conectividad de las celdas, normalmente se lo - llama *mutator* (mutador). +para el recolector de basura, lo único que interesa conocer del programa en +sí son los cambios al grafo de conectividad de las celdas, normalmente se lo +llama *mutator* (mutador). -- 2.43.0