Este programa fue escrito por Oskar Linde y nuevamente hallado__ en el grupo
de noticias. Fue construido para mostrar como el hecho de que el recolector
sea conservativo puede hacer que al leer datos binarios hayan muchos *falsos
-punteros* que mantengan vivas celdas que en realidad ya no deberían ser
+positivos* que mantengan vivas celdas que en realidad ya no deberían ser
accesibles desde el *root set* del grafo de conectividad.
__ http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=46407
Ambas opciones, reducen notablemente la variación en los resultados (ver
cuadro :vref:`t:sol-setarch`). Esto probablemente se debe a la naturaleza
conservativa del recolector, dado que la probabilidad de tener *falsos
-punteros* depende directamente de los valores de las direcciones de memoria,
+positivos* depende directamente de los valores de las direcciones de memoria,
aunque las pruebas en la que hay concurrencia involucrada, se siguen viendo
grandes variaciones, que probablemente estén vinculadas a problemas de
sincronización que se ven expuestos gracias al indeterminismo inherente a los
El aumento en el variación de los tiempos de ejecución al usar marcado preciso
probablemente se debe a lo siguiente: con marcado conservativo, debe estar
sobreviviendo a las recolecciones el total de memoria pedida por el programa,
-debido a falsos punteros (por eso no se observa prácticamente variación en el
+debido a *falsos positivos* (por eso no se observa prácticamente variación en el
tiempo de ejecución y memoria máxima consumida); al marcar con precisión
-parcial, se logra disminuir mucho la cantidad de falsos punteros, pero el
+parcial, se logra disminuir mucho la cantidad de *falsos positivos*, pero el
*stack* y la memoria estática, se sigue marcado de forma conservativa, por lo
tanto dependiendo de los valores (aleatorios) generados por la prueba, aumenta
-o disminuye la cantidad de falsos punteros, variando así la cantidad de
+o disminuye la cantidad de *falsos positivos*, variando así la cantidad de
memoria consumida y el tiempo de ejecución.
No se muestran los resultados para más de un procesador por ser demasiado
para TBGC se ve una variación entre los resultados muy grande que desaparece
al cambiar a CDGC, esto no puede ser explicado por esa optimización. En
general la disminución de la variación de los resultados hemos visto que está
-asociada al incremento en la precisión en el marcado, dado que los falsos
-punteros ponen una cuota de aleatoriedad importante. Pero este tampoco parece
-ser el caso, ya que no se observan cambios apreciables al pasar a usar marcado
-preciso.
+asociada al incremento en la precisión en el marcado, dado que los *falsos
+positivos* ponen una cuota de aleatoriedad importante. Pero este tampoco
+parece ser el caso, ya que no se observan cambios apreciables al pasar a usar
+marcado preciso.
Lo que se observa en esta oportunidad es un caso patológico de un mal factor
de ocupación del *heap* (ver :ref:`sol_ocup`). Lo que muy probablemente está
============== ============== ============== =================
El pequeño incremento en el tiempo total de ejecución podría estar dado por la
-mayor probabilidad de tener *falsos punteros* debido al incremento del tamaño
+mayor probabilidad de tener *falsos positivos* debido al incremento del tamaño
del *heap*; se recuerda que el *stack* y memoria estática se siguen marcado de
forma conservativa, incluso en modo preciso.
projects / z.facultad / 75.00 / informe.git / blobdiff