[Pharo-project] Reify the VM in the image [WAS] Why we have Behavior >> flushCache?

Guillermo Polito guillermopolito at gmail.com
Tue Apr 26 21:07:40 CEST 2011


+1

BTW, in the case where it's natural to have a flushCache in behavior, I'd
like to have it in the class side, not the instance side.

On Tue, Apr 26, 2011 at 3:56 PM, Mariano Martinez Peck <
marianopeck at gmail.com> wrote:

> Let's change the name of the thread :)
>
> 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
> senders.
>
> In fact, in Pharo 1.3, the method SmalltalkImage >> vm
>     "Answer the object to query about virtual machine."
>
>     ^self
>
> 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:
> -#vmParameterAt:put:
> - #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.
>
> Cheers
>
> Mariano
>
>
>
>>
>> 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
>>>
>>>
>>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>
>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gforge.inria.fr/pipermail/pharo-project/attachments/20110426/80cf1b98/attachment.htm>


More information about the Pharo-project mailing list