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 at gmail.com>:
> 
>
>       On Mon, Nov 3, 2014 at 10:32 AM, Levente Uzonyi <leves at 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
> 
> 
> 
> 
> 
>