Corregir indentación

diff --git a/source/dgc.rst b/source/dgc.rst
index a457444c2ebe0d90bd3a352eb294307a02e48708..11d0c0c0a00f588e223f20d18e74ed2f3ca5db2f 100644 (file)
--- 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 6abc764357d16f414b1794df82df06d28af10bc1..a221059fe528cf0a2d1bf863a929225592182585 100644 (file)
--- 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).