[Pharo-project] Why we have Behavior >> flushCache?
Mariano Martinez Peck
marianopeck at gmail.com
Tue Apr 26 13:23:26 CEST 2011
On Tue, Apr 26, 2011 at 12:51 PM, Stéphane Ducasse <
stephane.ducasse at inria.fr> wrote:
> what is the cache flushed?
what or when?
What ? it flushed all the method lookup cache
when? ok, for our refactoring the only thing that matters are the senders
in the image.
If you read the comment of the method it says "the method cache is flushed
on every programming change and garbage collect"
However, that seems not to be true. If I do a garbageCollect,
Behavior>>flushCache is not sent (not even the primitive), And "every
programming change" I don't know what it is.
The senders I see in the image are:
- Behavior >> superclass: aClass (it does a Object flushCache)
- Time class >> benchmarkMillisecondClock (it does a Object flushCache.)
- Time class >> benchmarkPrimitiveResponseDelay (it does a Object
So, in fact, as much as I can see, all the senders of Behavior>>flushCache
are sent to Object and not to a class in particular. Hence, it is one more
probe that such method is independent of the receiver.
I think that your point is valid and it would be good to do it.
> On Apr 26, 2011, at 12:34 PM, Mariano Martinez Peck wrote:
> > Hi. As far as I can see,
> > Behavior >> flushCache
> > "Tell the interpreter to remove the contents of its method lookup
> cache, if it has
> > one. Essential. See Object documentation whatIsAPrimitive."
> > <primitive: 89>
> > self primitiveFailed
> > And primitive 89 does nothing in particular with the receiver (the class
> in this case). In both, InterpreterVM and Cog, the WHOLE cache is flushed,
> there is NOTHING related to the receiver class. Of course, that's at least
> what it looks for me (please tell me if I am wrong).
> > So...if this is the case, wouldn't make sense to move it elsewhere? like
> Smalltalk flushCache or Smalltalk vm flushCache (and it is a good moment to
> reify the VM). So after we can do: Smalltalk vm version. Smalltlak vm
> flushCache, Smalltalk vm parameterAt: , etc....
> > If you don't like doing "Smalltalk vm" then we can create a VM class with
> all class methods, or a singleton and use #current or a singleton and put it
> in Smalltalk globals...etc
> > We will need to fix a couple of senders, thus.
> > What do you think? For me is really confusing, and you don't understand
> it until you see the primitive implementation.
> > Cheers
> > --
> > Mariano
> > http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pharo-project