[Pharo-project] Why we have Behavior >> flushCache?
eliot.miranda at gmail.com
Tue Apr 26 18:59:17 CEST 2011
the point is that it is classes that manage adding methods to classes
and hence it is their private behavior to flush the VM's method cache.
You'll see "self flushCache" in Smalltalk-80 v2 images. Now of course the
VM provides selective cache flushing but back in the day adding or removing
a method implied flushing the whole cache. Personally I don't see that this
justifies adding Smalltalk vm yet. I would wait until you have a few more
On Tue, Apr 26, 2011 at 3:34 AM, Mariano Martinez Peck <
marianopeck at gmail.com> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pharo-project