[Pharo-project] Why we have Behavior >> flushCache?
luc.fabresse at gmail.com
Thu Apr 28 11:19:37 CEST 2011
2011/4/26 Mariano Martinez Peck <marianopeck at gmail.com>
> On Tue, Apr 26, 2011 at 6:59 PM, Eliot Miranda <eliot.miranda at gmail.com>wrote:
>> 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.
Yes I agree Mariano.
And I also suggest to put meaningful selectors for vmparameters because I
can't remember the indexes.
^ self vmParameterAt: 49
>> 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.
-------------- section suivante --------------
Une pi?ce jointe HTML a ?t? nettoy?e...
More information about the Pharo-project