flushCache

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

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 <[hidden email]>:

On Mon, Nov 3, 2014 at 10:32 AM, Levente Uzonyi <[hidden email]> 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 <[hidden email]>:


      On Mon, Nov 3, 2014 at 10:32 AM, Levente Uzonyi <[hidden email]> 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