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 <[email protected]> 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 > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
