Re: [Pharo-project] [squeak-dev] runSimulated behaviour
Hi Michael, Michael, Dennis, Hi All, I think this is a simple bug in ContextPart >> #tryNamedPrimitiveIn:for:withArgs:, which neglects to flush the method cache for the method and/or selector used to simulate execution of a named primitive. With the relevant flushCacher calls added I no longer see any of the simulation failures recently experienced (someMethod getSourceFromFile, TimeStamp now). Please test the attached and let me know how you get on. The problem is caused by using the same method to invoke differet primitives in quick succession where, because the method cache is not flushed, the wrong primitive (a previous primitive) is left in the cache and invoked instead of the desired primitive. In Cog I added a primitive to directly evaluate a named primitive so the problem does not occur. Adding the two lines marked >> below fixes the problem. The line "theMethod flushCache" is probably more than we need, but does not harm. HTH Eliot !ContextPart methodsFor: 'private' stamp: 'eem 5/23/2010 14:13'! tryNamedPrimitiveIn: aCompiledMethod for: aReceiver withArgs: arguments "Hack. Attempt to execute the named primitive from the given compiled method" | selector theMethod spec | arguments size > 8 ifTrue:[^PrimitiveFailToken]. selector := #( tryNamedPrimitive tryNamedPrimitive: tryNamedPrimitive:with: tryNamedPrimitive:with:with: tryNamedPrimitive:with:with:with: tryNamedPrimitive:with:with:with:with: tryNamedPrimitive:with:with:with:with:with: tryNamedPrimitive:with:with:with:with:with:with: tryNamedPrimitive:with:with:with:with:with:with:with:) at: arguments size+1. theMethod := aReceiver class lookupSelector: selector. theMethod == nil ifTrue:[^PrimitiveFailToken]. spec := theMethod literalAt: 1. spec replaceFrom: 1 to: spec size with: (aCompiledMethod literalAt: 1) startingAt: 1.
theMethod flushCache. selector flushCache. ^aReceiver perform: selector withArguments: arguments! !
On Thu, May 20, 2010 at 2:55 AM, Michael Haupt <mhaupt@gmail.com> wrote:
Dear all,
we're observing some strange behaviour in simulated bytecode execution in Squeak (4.1, on Macs).
Printing this: ContextPart runSimulated: [ TimeStamp now ] will work once and then reproducibly fail with code simulation errors.
This works well (also reproducibly): ContextPart trace: [ TimeStamp now ]
Going to more detail, we figured out that simulation reproducibly works if things are written to the Transcript every now and then. Printing this: n:=0. thisContext runSimulated: [ TimeStamp now ] contextAtEachStep: [ :c | n\\100=0 ifTrue: [ Transcript show: $. ] ] works.
We've tried to just insert some artificial delays (<someValue> milliSeconds asDelay wait) in the block, but that will not reproducibly work; it also leads to code simulation errors. So it can't be just the time it takes to write to Transcript. Or so we believe.
Does anybody know the reason for this strange behaviour, or where in the simulation logic to look?
Best,
Michael
tx! On May 23, 2010, at 11:24 PM, Eliot Miranda wrote:
Hi Michael, Michael, Dennis, Hi All,
I think this is a simple bug in ContextPart >> #tryNamedPrimitiveIn:for:withArgs:, which neglects to flush the method cache for the method and/or selector used to simulate execution of a named primitive. With the relevant flushCacher calls added I no longer see any of the simulation failures recently experienced (someMethod getSourceFromFile, TimeStamp now). Please test the attached and let me know how you get on.
The problem is caused by using the same method to invoke differet primitives in quick succession where, because the method cache is not flushed, the wrong primitive (a previous primitive) is left in the cache and invoked instead of the desired primitive. In Cog I added a primitive to directly evaluate a named primitive so the problem does not occur. Adding the two lines marked >> below fixes the problem. The line "theMethod flushCache" is probably more than we need, but does not harm.
HTH Eliot
!ContextPart methodsFor: 'private' stamp: 'eem 5/23/2010 14:13'! tryNamedPrimitiveIn: aCompiledMethod for: aReceiver withArgs: arguments "Hack. Attempt to execute the named primitive from the given compiled method" | selector theMethod spec | arguments size > 8 ifTrue:[^PrimitiveFailToken]. selector := #( tryNamedPrimitive tryNamedPrimitive: tryNamedPrimitive:with: tryNamedPrimitive:with:with: tryNamedPrimitive:with:with:with: tryNamedPrimitive:with:with:with:with: tryNamedPrimitive:with:with:with:with:with: tryNamedPrimitive:with:with:with:with:with:with: tryNamedPrimitive:with:with:with:with:with:with:with:) at: arguments size+1. theMethod := aReceiver class lookupSelector: selector. theMethod == nil ifTrue:[^PrimitiveFailToken]. spec := theMethod literalAt: 1. spec replaceFrom: 1 to: spec size with: (aCompiledMethod literalAt: 1) startingAt: 1.
theMethod flushCache. selector flushCache. ^aReceiver perform: selector withArguments: arguments! !
On Thu, May 20, 2010 at 2:55 AM, Michael Haupt <mhaupt@gmail.com> wrote: Dear all,
we're observing some strange behaviour in simulated bytecode execution in Squeak (4.1, on Macs).
Printing this: ContextPart runSimulated: [ TimeStamp now ] will work once and then reproducibly fail with code simulation errors.
This works well (also reproducibly): ContextPart trace: [ TimeStamp now ]
Going to more detail, we figured out that simulation reproducibly works if things are written to the Transcript every now and then. Printing this: n:=0. thisContext runSimulated: [ TimeStamp now ] contextAtEachStep: [ :c | n\\100=0 ifTrue: [ Transcript show: $. ] ] works.
We've tried to just insert some artificial delays (<someValue> milliSeconds asDelay wait) in the block, but that will not reproducibly work; it also leads to code simulation errors. So it can't be just the time it takes to write to Transcript. Or so we believe.
Does anybody know the reason for this strange behaviour, or where in the simulation logic to look?
Best,
Michael
<ContextPart-tryNamedPrimitiveInforwithArgs.st>_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (2)
-
Eliot Miranda -
Stéphane Ducasse