[squeak-dev] flushCache
Levente Uzonyi
leves at elte.hu
Mon Nov 3 22:04:03 UTC 2014
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
>
>
>
>
>
>
More information about the Squeak-dev
mailing list
|