[Pharo-project] Why we have Behavior >> flushCache?

Mariano Martinez Peck marianopeck at gmail.com
Tue Apr 26 20:36:02 CEST 2011

On Tue, Apr 26, 2011 at 6:59 PM, Eliot Miranda <eliot.miranda at gmail.com>wrote:

> Mariano,
>     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.

Ok...I agree, but still it is misleading when we are talking about "method
cache". Because methods are in classes...so I promise everybody that didn't
know and you ask what Behavior >> flushCache does, and everybody will say
that it flushed the cache of the methods of that class, not the whole cache.
I can understand CompiledMethod >> flushCache and even Symbol >> flushCache
... but this one looks really strange.

> You'll see "self flushCache" in Smalltalk-80 v2 images.

that makes more sense indeed

>  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 use cases.

Sorry but in this case, I disagree. I think the opposite: it is the perfect
moment to reify the VM in the image and start using it. Why?  exactly
because right now we have few uses and it is really easy to migrate. In
fact, for Behavior >> flushCache there are only 3 senders.  And I don't
pretend to remove them right now, but with the normal deprecation policy.
This is, in Pharo 1.3 we let the messages like Behavior >> flushCache,
SmalltalkImage >> vmVersion, etc. But we let them as deprecated explaining
that now they should use XXX. And of course, inside the image we do fix the

In fact, in Pharo 1.3, the method SmalltalkImage >> vm
    "Answer the object to query about virtual machine."


already exists :)

I see the following possible behavior for VM right now (I mean, the
following methods are already in SmalltalkImage):

- #flushCache
- #buildDate
- #interpreterSourceVersion
- #platformSourceVersion
- #versionLabel
- #extraVMMemory
- #extraVMMemory:
- #gcBiasToGrow:
- #gcBiasToGrowLimit:
- #getVMParameters
- #primitiveGCBiasToGrow:
- #vmParameterAt:
- #reportCPUandRAM
- #vmStatisticsReportString
- #vmStatisticsShortString

So....I think they are enough. And the sooner we do this, the easier it
would be to reify the VM in the image.



> 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.
>> Cheers
>> --
>> Mariano
>> http://marianopeck.wordpress.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gforge.inria.fr/pipermail/pharo-project/attachments/20110426/b17c4dd5/attachment.htm>

More information about the Pharo-project mailing list