> El tema de simular los metodos nativos y todo eso debe ser mucho mas
> agradable que gdb (o, mucho peor, WinDBG). Pero tambien hay que tener
> en cuenta que seguramente en esa simulacion el tema de signals e
> interrupciones no es una simulacion fiel de lo que pasa en realidad.
Ahora me acorde de un efecto parecido en VisualWorks. La maquina
virtual tiene unos switches para prender tests de debug que se
ejecutan mientras Smalltalk corre. Uno de esos switches es -o11s.
Hay que prenderlos a manopla porque todo se vuelve hiper lento. En
particular, el IGC tiene un test que se ejecuta con -o11s, y como el
test es verificar que la imagen este sana tarda como 1 segundo.
Y que pasa cuando el idle loop, que corre con prioridad 10, trata de
ejecutar el IGC en modo interrumpible? Basicamente, en este metodo,
idleLoopAction
"Run the incremental GC until interrupted if the potential benefits
seem to warrant the effort. This message should be sent only if the
system has nothing better to do."
self updateMemoryStatus.
self tooManyAllocationProbes ifTrue:
[self primeThreadedDataList ifFalse:
[[self compactData] forkAt: Processor
userInterruptPriority]].
self idleLoopGCJustified ifTrue:
[[ObjectMemory
primIncrementalGCIsInterruptable: true
objects: SmallInteger maxVal
bytes: SmallInteger maxVal.
self updateMemoryStatus.
memoryStatus incrementalGCState == #resting] whileFalse.
NumScavengesAsOfLastGC := memoryStatus numScavenges.
ObjectMemory resetSpaceLimitsIfHigher.
self dataNeedsCompacting ifTrue:
[[self compactData] forkAt: Processor
userInterruptPriority]]
eventualmente self idleLoopGCJustified es true. Asi que entra al
branch de ifTrue: y ahi adentro hay un whileFalse que va a seguir
tratando de ejecutar el IGC hasta que el incrementalGCState sea
#resting. Pero cuando llamas a la primitiva, el codigo basicamente
hace
primitivaDelIGC()
{
/* test de un segundo */
/* el IGC */
}
Ahora bien, como se ve en el metodo, el IGC es interruptable. Eso
quiere decir que si cae cualquier señal, como ser mover un mouse, o
que se dispare un timer, etc, entonces el IGC va a interrumpirse a si
mismo. El tema es que el test de un segundo hace que, para cuando la
VM llega al codigo del IGC, siempre cayo una interrupcion. Por lo
tanto el IGC nunca termina y entonces con -o11s el idle loop empieza a
gastar 100% de CPU en tandas de 1 segundo...
Pero quien dice test de 1 segundo puede haber dicho overhead de
simulacion. Es todo un tema eso de andar simulando cosas, porque se
introducen efectos no deseados que pueden hacer saltar problemas que
en la practica no existen, u ocultar problemas que en la practica
pasan mayormente desapercibidos.
Andres.
--
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
http://www.clubSmalltalk.org
