X-Git-Url: https://git.llucax.com/z.facultad/75.00/informe.git/blobdiff_plain/93304243d72347314f0d9c402a0632ab50550016..409ef528d2b45bdcbcd6868b3d0f82c1edf8e748:/source/dgc.rst diff --git a/source/dgc.rst b/source/dgc.rst index 09c0c21..370b664 100644 --- a/source/dgc.rst +++ b/source/dgc.rst @@ -238,9 +238,9 @@ dicho objeto. para indicar la continuación de un objeto grande (que ocupan más de una página). -.. fig:: fig:dgc-org +.. flt:: fig:dgc-org - Organización del *heap* del recolector de basura actual de D. + Organización del *heap* del recolector de basura actual de D Organización del *heap*. En este ejemplo todos los *pools* tienen 2 páginas excepto el *pool* 2 que tiene una sola. El tamaño de bloque que almacena @@ -304,9 +304,9 @@ parte de una :ref:`lista de libres ` (ver figura :vref:`fig:dgc-free-list`). Esto permite asignar objetos relativamente pequeños de forma bastante eficiente. -.. fig:: fig:dgc-free-list +.. flt:: fig:dgc-free-list - Ejemplo de listas de libres. + Ejemplo de listas de libres .. digraph:: dgc_free_list @@ -854,9 +854,9 @@ siguiente función, que devuelve al *low level allocator* los *pools* completamente libres:: function minimize() is - for pool in heap + foreach pool in heap all_free = true - for page in pool + foreach page in pool if page.block_size is not FREE all_free = false break @@ -1058,6 +1058,28 @@ C ``malloc()``, ``realloc()`` y ``free()`` directamente. La estructura ``Pool`` está compuesta por los siguientes atributos (ver figura :vref:`fig:dgc-pool`): +.. flt:: fig:dgc-pool + + Vista gráfica de la estructura de un *pool* de memoria + + .. aafig:: + :scale: 120 + + /--- "baseAddr" "ncommitted = i" "topAddr" ---\ + | V | + |/ |/ |/ + +---- "committed" -----+------- "no committed" ----------+ + /| /| /| + V V V + +--------+--------+-----+--------+-----+-------------------+ + páginas | 0 | 0 | ... | i | ... | "npages - 1" | + +--------+--------+-----+--------+-----+-------------------+ + A A A A A A + | | | | | | + +--------+--------+-----+--------+-----+-------------------+ + pagetable | Bins 0 | Bins 1 | ... | Bins i | ... | "Bins (npages-1)" | + +--------+--------+-----+--------+-----+-------------------+ + *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 @@ -1088,28 +1110,6 @@ La estructura ``Pool`` está compuesta por los siguientes atributos (ver figura ``B_UNCOMMITTED`` (valor que tienen las páginas que no fueron encomendadas aún) y ``B_FREE``. -.. fig:: fig:dgc-pool - - Vista gráfica de la estructura de un *pool* de memoria. - - .. aafig:: - :scale: 120 - - /--- "baseAddr" "ncommitted = i" "topAddr" ---\ - | V | - |/ |/ |/ - +---- "committed" -----+------- "no committed" ----------+ - /| /| /| - V V V - +--------+--------+-----+--------+-----+-------------------+ - páginas | 0 | 0 | ... | i | ... | "npages - 1" | - +--------+--------+-----+--------+-----+-------------------+ - A A A A A A - | | | | | | - +--------+--------+-----+--------+-----+-------------------+ - pagetable | Bins 0 | Bins 1 | ... | Bins i | ... | "Bins (npages-1)" | - +--------+--------+-----+--------+-----+-------------------+ - Como se observa, además de la información particular del *pool* se almacena toda la información de páginas y bloques enteramente en el *pool* también. Esto simplifica el manejo de que lo es memoria *pura* del *heap*, ya que queda @@ -1480,9 +1480,9 @@ Las opciones más importantes son: bits estén intactas. Esto permite detectar de forma temprana errores tanto en el recolector como en el programa del usuario. - .. fig:: fig:sentinel + .. flt:: fig:sentinel - Esquema de un bloque cuando está activada la opción ``SENTINEL``. + Esquema de un bloque cuando está activada la opción ``SENTINEL`` .. aafig:: :textual: @@ -1533,6 +1533,8 @@ recolector actual y en consecuencia sea muy complicado escribir documentación o mejorarlo. Esto a su vez provoca que, al no disponer de una implementación de referencia sencilla, sea muy difícil implementar un recolector nuevo. +.. highlight:: d + Este es, probablemente, la raíz de todos los demás problemas del recolector actual. Para ilustrar la dimensión del problema se presenta la implementación real de la función ``bigAlloc()``:: @@ -1654,7 +1656,7 @@ esporádicamente [NGD54084]_ [NGL13744]_. De todas maneras queda mucho lugar para mejoras, y es un tema recurrente en el grupo de noticias de D_ y se han discutido formas de poder hacer que, al menos el *heap* sea preciso [NGD44607]_ [NGD29291]_. Además se mostró un interés -general por tener un recolector más preciso [NGDN87831]_, pero no han habido +general por tener un recolector más preciso [NGD87831]_, pero no han habido avances al respecto. Otra forma de minimizar los efectos de la falta de precisión que se ha @@ -1692,13 +1694,13 @@ sincronización excesivo. Se ha sugerido en el pasado el uso de *pools* y listas de libres específicos de hilos, de manera de disminuir la contención, al menos para la asignación de -memoria [NGD75952]_ [NGDN87831]_. +memoria [NGD75952]_ [NGD87831]_. Además se ha mostrado un interés por tener un nivel de concurrencia aún mayor en el recolector, para aumentar la concurrencia en ambientes *multi-core* en general pero en particular para evitar grandes pausas en programas con requerimientos de tiempo real, históricamente una de las principales críticas -al lenguaje [NGDN87831]_ [NGL3937]_ [NGD22968]_ [NGA15246]_ [NGD5622]_ +al lenguaje [NGD87831]_ [NGL3937]_ [NGD22968]_ [NGA15246]_ [NGD5622]_ [NGD2547]_ [NGD18354]_. @@ -1915,8 +1917,8 @@ base del algoritmo del recolector de basura actual. En general en la comunidad de D_ no hay mayores críticas al marcado y barrido en sí, si no más bien a problemas asociados a la implementación actual, principalmente a las grandes pausas o la falta de :ref:`precisión -` [NGD54084]_ [NGL13744]_ [NGD44607]_ [NGD29291]_ [NGDN87831]_ -[NGDN87831]_ [NGL3937]_ [NGD22968]_ [NGA15246]_ [NGD5622]_ [NGD2547]_ +` [NGD54084]_ [NGL13744]_ [NGD44607]_ [NGD29291]_ [NGD87831]_ +[NGD87831]_ [NGL3937]_ [NGD22968]_ [NGA15246]_ [NGD5622]_ [NGD2547]_ [NGD18354]_. Esta familia de algoritmos se adapta bien a los requerimientos principales de