Hi All,
We have three primitives for three different versions of #flushCache: - primitive 89 used by Behavior >> #flushCache - primitive 116 used by CompiledMethod >> #flushCache - primitive 119 used by Symbol >> #flushCache
Based on the comment in CompiledMethod >> #flushCache, and Symbol >> #flushCache, primitive 119 is not used since Squeak 2.3, and Symbol >> #flushCache can safely be removed. But the method is still in the image, and it is being sent whenever a method is removed or added to a class. Is the comment wrong, or the method is really not needed?
Also the last comments in Behavior >> #basicAddSelector:withMethod: and Behavior >> #basicRemoveSelector: suggest that either the method's or the selector's cache should be flushed, but not both, which is actually the case in both methods. The comment in Symbol >> #flushCache suggests the same. So what's the truth? Do we still need primitive 119?
Levente
On Mon, Nov 3, 2014 at 10:32 AM, Levente Uzonyi leves@elte.hu wrote:
Hi All,
We have three primitives for three different versions of #flushCache:
- primitive 89 used by Behavior >> #flushCache
- primitive 116 used by CompiledMethod >> #flushCache
- primitive 119 used by Symbol >> #flushCache
Based on the comment in CompiledMethod >> #flushCache, and Symbol >> #flushCache, primitive 119 is not used since Squeak 2.3, and Symbol >> #flushCache can safely be removed.
NO!!! This is completely wrong. Symbol>>#flushCache is the one that *must* be there. The use of 116 is IMO completely bogus. For the VM to use 116 effectively it must be able to find the selector in the method; in general not possible because the selector is only optional in a method, optionally in the penultimate literal, but perhaps inside the penultimate literal, and perhaps the method is an anonymous accessor only copied into a method dictionary. Caches in the VM are based on *selectors* (arguably these may not even be symbols; see below) and flushing entries that refer to a particular compiled method may not correctly update caches on subclass or superclass methods. Whereas flushing based on selector, even if it does more work, always reliably upates caches correctly.
In general message selectors can be any object, so one could aggressively shrink by e.g. replacing all selectors by SmallIntegers. This was done back in the day with the ActiveBook system, an early tablet implemented largely in Smalltalk. So primitive 119 should IMO be implemented in Object.
But the method is still in the image, and it is being sent whenever a method is removed or added to a class. Is the comment wrong, or the method is really not needed?
The comment is wrong.
Also the last comments in Behavior >> #basicAddSelector:withMethod: and
Behavior >> #basicRemoveSelector: suggest that either the method's or the selector's cache should be flushed, but not both, which is actually the case in both methods. The comment in Symbol >> #flushCache suggests the same. So what's the truth? Do we still need primitive 119?
Yes, we do, and only it should be used in Behavior >> #basicAddSelector:withMethod: and Behavior >> #basicRemoveSelector:.
Levente
I think Eliot already explained this in this vm-dev thread [Vm-dev] About primitive for cleaning compiled method cache http://lists.squeakfoundation.org/pipermail/vm-dev/2013-March/012333.html
2014-11-03 19:42 GMT+01:00 Eliot Miranda eliot.miranda@gmail.com:
On Mon, Nov 3, 2014 at 10:32 AM, Levente Uzonyi leves@elte.hu wrote:
Hi All,
We have three primitives for three different versions of #flushCache:
- primitive 89 used by Behavior >> #flushCache
- primitive 116 used by CompiledMethod >> #flushCache
- primitive 119 used by Symbol >> #flushCache
Based on the comment in CompiledMethod >> #flushCache, and Symbol >> #flushCache, primitive 119 is not used since Squeak 2.3, and Symbol >> #flushCache can safely be removed.
NO!!! This is completely wrong. Symbol>>#flushCache is the one that *must* be there. The use of 116 is IMO completely bogus. For the VM to use 116 effectively it must be able to find the selector in the method; in general not possible because the selector is only optional in a method, optionally in the penultimate literal, but perhaps inside the penultimate literal, and perhaps the method is an anonymous accessor only copied into a method dictionary. Caches in the VM are based on *selectors* (arguably these may not even be symbols; see below) and flushing entries that refer to a particular compiled method may not correctly update caches on subclass or superclass methods. Whereas flushing based on selector, even if it does more work, always reliably upates caches correctly.
In general message selectors can be any object, so one could aggressively shrink by e.g. replacing all selectors by SmallIntegers. This was done back in the day with the ActiveBook system, an early tablet implemented largely in Smalltalk. So primitive 119 should IMO be implemented in Object.
But the method is still in the image, and it is being sent whenever a method is removed or added to a class. Is the comment wrong, or the method is really not needed?
The comment is wrong.
Also the last comments in Behavior >> #basicAddSelector:withMethod: and
Behavior >> #basicRemoveSelector: suggest that either the method's or the selector's cache should be flushed, but not both, which is actually the case in both methods. The comment in Symbol >> #flushCache suggests the same. So what's the truth? Do we still need primitive 119?
Yes, we do, and only it should be used in Behavior >> #basicAddSelector:withMethod: and Behavior >> #basicRemoveSelector:.
Levente
-- best, Eliot
On Mon, Nov 3, 2014 at 1:11 PM, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
I think Eliot already explained this in this vm-dev thread [Vm-dev] About primitive for cleaning compiled method cache http://lists.squeakfoundation.org/pipermail/vm-dev/2013-March/012333.html
Right. http://lists.squeakfoundation.org/pipermail/vm-dev/2013-March/012359.html
2014-11-03 19:42 GMT+01:00 Eliot Miranda eliot.miranda@gmail.com:
On Mon, Nov 3, 2014 at 10:32 AM, Levente Uzonyi leves@elte.hu wrote:
Hi All,
We have three primitives for three different versions of #flushCache:
- primitive 89 used by Behavior >> #flushCache
- primitive 116 used by CompiledMethod >> #flushCache
- primitive 119 used by Symbol >> #flushCache
Based on the comment in CompiledMethod >> #flushCache, and Symbol >> #flushCache, primitive 119 is not used since Squeak 2.3, and Symbol >> #flushCache can safely be removed.
NO!!! This is completely wrong. Symbol>>#flushCache is the one that *must* be there. The use of 116 is IMO completely bogus. For the VM to use 116 effectively it must be able to find the selector in the method; in general not possible because the selector is only optional in a method, optionally in the penultimate literal, but perhaps inside the penultimate literal, and perhaps the method is an anonymous accessor only copied into a method dictionary. Caches in the VM are based on *selectors* (arguably these may not even be symbols; see below) and flushing entries that refer to a particular compiled method may not correctly update caches on subclass or superclass methods. Whereas flushing based on selector, even if it does more work, always reliably upates caches correctly.
In general message selectors can be any object, so one could aggressively shrink by e.g. replacing all selectors by SmallIntegers. This was done back in the day with the ActiveBook system, an early tablet implemented largely in Smalltalk. So primitive 119 should IMO be implemented in Object.
But the method is still in the image, and it is being sent whenever a method is removed or added to a class. Is the comment wrong, or the method is really not needed?
The comment is wrong.
Also the last comments in Behavior >> #basicAddSelector:withMethod: and
Behavior >> #basicRemoveSelector: suggest that either the method's or the selector's cache should be flushed, but not both, which is actually the case in both methods. The comment in Symbol >> #flushCache suggests the same. So what's the truth? Do we still need primitive 119?
Yes, we do, and only it should be used in Behavior >> #basicAddSelector:withMethod: and Behavior >> #basicRemoveSelector:.
Levente
-- best, Eliot
On Mon, 3 Nov 2014, Nicolas Cellier wrote:
I think Eliot already explained this in this vm-dev thread [Vm-dev] About primitive for cleaning compiled method cache http://lists.squeakfoundation.org/pipermail/vm-dev/2013-March/012333.html
Thanks Eliot and Nicolas. So IUUC we don't have to use primitive 116 from Behavior >> #basicAddSelector:withMethod: and Behavior >> #basicRemoveSelector: anymore. Is that right?
I took a quick look at the implementation of the MethodCache, and I was wondering why is the probe loop unrolled by hand in #lookupInMethodCacheSel:class(Tag):. This makes it hard to change the number of probes, and I assume that the C compiler would be able to unroll it just as well.
Levente
2014-11-03 19:42 GMT+01:00 Eliot Miranda eliot.miranda@gmail.com:
On Mon, Nov 3, 2014 at 10:32 AM, Levente Uzonyi <leves@elte.hu> wrote: Hi All, We have three primitives for three different versions of #flushCache: - primitive 89 used by Behavior >> #flushCache - primitive 116 used by CompiledMethod >> #flushCache - primitive 119 used by Symbol >> #flushCache Based on the comment in CompiledMethod >> #flushCache, and Symbol >> #flushCache, primitive 119 is not used since Squeak 2.3, and Symbol >> #flushCache can safely be removed.
NO!!! This is completely wrong. Symbol>>#flushCache is the one that *must* be there. The use of 116 is IMO completely bogus. For the VM to use 116 effectively it must be able to find the selector in the method; in general not possible because the selector is only optional in a method, optionally in the penultimate literal, but perhaps inside the penultimate literal, and perhaps the method is an anonymous accessor only copied into a method dictionary. Caches in the VM are based on *selectors* (arguably these may not even be symbols; see below) and flushing entries that refer to a particular compiled method may not correctly update caches on subclass or superclass methods. Whereas flushing based on selector, even if it does more work, always reliably upates caches correctly.
In general message selectors can be any object, so one could aggressively shrink by e.g. replacing all selectors by SmallIntegers. This was done back in the day with the ActiveBook system, an early tablet implemented largely in Smalltalk. So primitive 119 should IMO be implemented in Object. But the method is still in the image, and it is being sent whenever a method is removed or added to a class. Is the comment wrong, or the method is really not needed?
The comment is wrong.
Also the last comments in Behavior >> #basicAddSelector:withMethod: and Behavior >> #basicRemoveSelector: suggest that either the method's or the selector's cache should be flushed, but not both, which is actually the case in both methods. The comment in Symbol >> #flushCache suggests the same. So what's the truth? Do we still need primitive 119?
Yes, we do, and only it should be used in Behavior >> #basicAddSelector:withMethod: and Behavior >> #basicRemoveSelector:.
Levente
-- best,Eliot
On Mon, Nov 3, 2014 at 2:04 PM, Levente Uzonyi leves@elte.hu wrote:
On Mon, 3 Nov 2014, Nicolas Cellier wrote:
I think Eliot already explained this in this vm-dev thread
[Vm-dev] About primitive for cleaning compiled method cache http://lists.squeakfoundation.org/pipermail/vm-dev/2013-March/012333.html
Thanks Eliot and Nicolas. So IUUC we don't have to use primitive 116 from Behavior >> #basicAddSelector:withMethod: and Behavior >> #basicRemoveSelector: anymore. Is that right?
Right. I think it's bogus. Just 119.
I took a quick look at the implementation of the MethodCache, and I was
wondering why is the probe loop unrolled by hand in #lookupInMethodCacheSel:class(Tag):. This makes it hard to change the number of probes, and I assume that the C compiler would be able to unroll it just as well.
It was ever that way. I could fix it I suppose. But it needs to be unrolled in the JIT's open PIC implementation anyway...
Levente
2014-11-03 19:42 GMT+01:00 Eliot Miranda eliot.miranda@gmail.com:
On Mon, Nov 3, 2014 at 10:32 AM, Levente Uzonyi <leves@elte.hu>
wrote: Hi All,
We have three primitives for three different versions of
#flushCache: - primitive 89 used by Behavior >> #flushCache - primitive 116 used by CompiledMethod >> #flushCache - primitive 119 used by Symbol >> #flushCache
Based on the comment in CompiledMethod >> #flushCache, and
Symbol >> #flushCache, primitive 119 is not used since Squeak 2.3, and Symbol >> #flushCache can safely be removed.
NO!!! This is completely wrong. Symbol>>#flushCache is the one that *must* be there. The use of 116 is IMO completely bogus. For the VM to use 116 effectively it must be able to find the selector in the method; in general not possible because the selector is only optional in a method, optionally in the penultimate literal, but perhaps inside the penultimate literal, and perhaps the method is an anonymous accessor only copied into a method dictionary. Caches in the VM are based on *selectors* (arguably these may not even be symbols; see below) and flushing entries that refer to a particular compiled method may not correctly update caches on subclass or superclass methods. Whereas flushing based on selector, even if it does more work, always reliably upates caches correctly.
In general message selectors can be any object, so one could aggressively shrink by e.g. replacing all selectors by SmallIntegers. This was done back in the day with the ActiveBook system, an early tablet implemented largely in Smalltalk. So primitive 119 should IMO be implemented in Object.
But the method is still in the image, and it is being sent whenever
a method is removed or added to a class. Is the comment wrong, or the method is really not needed?
The comment is wrong.
Also the last comments in Behavior >> #basicAddSelector:withMethod:
and Behavior >> #basicRemoveSelector: suggest that either the method's or the selector's cache should be flushed, but not both, which is actually the case in both methods. The comment in Symbol >> #flushCache suggests the same. So what's the truth? Do we still need primitive 119?
Yes, we do, and only it should be used in Behavior >> #basicAddSelector:withMethod: and Behavior >> #basicRemoveSelector:.
Levente
-- best,Eliot
squeak-dev@lists.squeakfoundation.org