Re: [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 <[hidden email]> 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project