[Pharo-project] Why we have Behavior >> flushCache?
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
what is the cache flushed? I think that your point is valid and it would be good to do it. Stef 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
On Tue, Apr 26, 2011 at 12:51 PM, Stéphane Ducasse < stephane.ducasse@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 flushCache.) 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.
Stef
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
-- Mariano http://marianopeck.wordpress.com
Not using the receiver is indeed misleading. I thought it simply flushes the cache for a particular class Alexandre On 26 Apr 2011, at 06:34, 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
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Tue, Apr 26, 2011 at 2:35 PM, Alexandre Bergel <alexandre.bergel@me.com>wrote:
Not using the receiver is indeed misleading. I thought it simply flushes the cache for a particular class
You are not alone :) That's why I am proposing the change. Of course, a nice comment could be enough (even if I muuuuch prefer to have it in elsewhere), but I think it may be a good moment to reify the VM and delegate a couple of things to it.
Alexandre
On 26 Apr 2011, at 06:34, 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
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
-- Mariano http://marianopeck.wordpress.com
How about putting such methods on an Interpreter class? On 2011-04-26, at 14:35, Alexandre Bergel wrote:
Not using the receiver is indeed misleading. I thought it simply flushes the cache for a particular class
Alexandre
On 26 Apr 2011, at 06:34, 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
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Tue, Apr 26, 2011 at 1:56 PM, Camillo Bruni <camillo.bruni@inria.fr>wrote:
How about putting such methods on an Interpreter class?
that's why I was saying by "reify the VM"
On 2011-04-26, at 14:35, Alexandre Bergel wrote:
Not using the receiver is indeed misleading. I thought it simply flushes the cache for a particular class
Alexandre
On 26 Apr 2011, at 06:34, 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
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
-- Mariano http://marianopeck.wordpress.com
On Tue, Apr 26, 2011 at 2:19 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
On Tue, Apr 26, 2011 at 1:56 PM, Camillo Bruni <camillo.bruni@inria.fr>wrote:
How about putting such methods on an Interpreter class?
that's why I was saying by "reify the VM"
but not Interpreter to avoid collisions with VMMaker. I would call it VirtualMachine- other ideas?
On 2011-04-26, at 14:35, Alexandre Bergel wrote:
Not using the receiver is indeed misleading. I thought it simply flushes the cache for a particular class
Alexandre
On 26 Apr 2011, at 06:34, 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
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
-- Mariano http://marianopeck.wordpress.com
-- Mariano http://marianopeck.wordpress.com
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. 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 use cases. On Tue, Apr 26, 2011 at 3:34 AM, Mariano Martinez Peck < marianopeck@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
On Tue, Apr 26, 2011 at 6:59 PM, Eliot Miranda <eliot.miranda@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@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
2011/4/26 Mariano Martinez Peck <marianopeck@gmail.com>
On Tue, Apr 26, 2011 at 6:59 PM, Eliot Miranda <eliot.miranda@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.
Yes I agree Mariano. And I also suggest to put meaningful selectors for vmparameters because I can't remember the indexes. e.g: VirtualMachine>>maximumNumberOfSemaphores ^ self vmParameterAt: 49 Luc
Cheers
Mariano
On Tue, Apr 26, 2011 at 3:34 AM, Mariano Martinez Peck < marianopeck@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
On 04/26/2011 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?
I don't see it so hard. When the method answers the cache of the receiving behavior is flushed. Sure the implementation is "naïve" in that it does more work than required but it satisfies the contract. Once you have a "better" implementation in the VM you don't need to change any code just because your VM got better. You don't need to write any detection code that checks what kind of VM you have. Cheers Philippe
participants (7)
-
Alexandre Bergel -
Camillo Bruni -
Eliot Miranda -
Luc Fabresse -
Mariano Martinez Peck -
Philippe Marschall -
Stéphane Ducasse