<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 3, 2014 at 2:04 PM, Levente Uzonyi <span dir="ltr"><<a href="mailto:leves@elte.hu" target="_blank">leves@elte.hu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, 3 Nov 2014, Nicolas Cellier wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think Eliot already explained this in this vm-dev thread<br>
[Vm-dev] About primitive for cleaning compiled method cache<br>
<a href="http://lists.squeakfoundation.org/pipermail/vm-dev/2013-March/012333.html" target="_blank">http://lists.squeakfoundation.<u></u>org/pipermail/vm-dev/2013-<u></u>March/012333.html</a><br>
</blockquote>
<br></span>
Thanks Eliot and Nicolas. So IUUC we don't have to use primitive 116 from Behavior >> #basicAddSelector:withMethod: and Behavior >> #basicRemoveSelector:<br>
anymore. Is that right?<br></blockquote><div><br></div><div>Right. I think it's bogus. Just 119.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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(<u></u>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.</blockquote><div><br></div><div>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...</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888">Levente</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
2014-11-03 19:42 GMT+01:00 Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>>:<br>
<br>
<br>
On Mon, Nov 3, 2014 at 10:32 AM, Levente Uzonyi <<a href="mailto:leves@elte.hu" target="_blank">leves@elte.hu</a>> wrote:<br>
Hi All,<br>
<br>
We have three primitives for three different versions of #flushCache:<br>
- primitive 89 used by Behavior >> #flushCache<br>
- primitive 116 used by CompiledMethod >> #flushCache<br>
- primitive 119 used by Symbol >> #flushCache<br>
<br>
Based on the comment in CompiledMethod >> #flushCache, and Symbol >> #flushCache, primitive 119 is not used since Squeak<br>
2.3, and Symbol >> #flushCache can safely be removed.<br>
<br>
<br>
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<br>
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<br>
a method, optionally in the penultimate literal, but perhaps inside the penultimate literal, and perhaps the method is an anonymous accessor<br>
only copied into a method dictionary.<br>
Caches in the VM are based on *selectors* (arguably these may not even be symbols; see below) and flushing entries that refer to a<br>
particular compiled method may not correctly update caches on subclass or superclass methods. Whereas flushing based on selector, even if<br>
it does more work, always reliably upates caches correctly.<br>
<br>
In general message selectors can be any object, so one could aggressively shrink by e.g. replacing all selectors by SmallIntegers. This was<br>
done back in the day with the ActiveBook system, an early tablet implemented largely in Smalltalk. So primitive 119 should IMO be<br>
implemented in Object.<br>
<br>
But the method is still in the image, and it is being sent whenever a method is removed or added to a class.<br>
Is the comment wrong, or the method is really not needed?<br>
<br>
<br>
The comment is wrong.<br>
<br>
Also the last comments in Behavior >> #basicAddSelector:withMethod: and Behavior >> #basicRemoveSelector: suggest that either<br>
the method's or the selector's cache should be flushed, but not both, which is actually the case in both methods.<br>
The comment in Symbol >> #flushCache suggests the same. So what's the truth? Do we still need primitive 119?<br>
<br>
<br>
Yes, we do, and only it should be used in Behavior >> #basicAddSelector:withMethod: and Behavior >> #basicRemoveSelector:.<br>
<br>
<br>
<br>
Levente<br>
<br>
<br>
<br>
<br>
--<br>
best,Eliot<br>
<br>
<br>
<br>
<br>
<br>
</blockquote>
</div></div><br><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">best,<div>Eliot</div></div>
</div></div>