<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2016-03-14 18:08 GMT+01:00 Chris Cunnington <span dir="ltr">&lt;<a href="mailto:brasspen@gmail.com" target="_blank">brasspen@gmail.com</a>&gt;</span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> <br><div style="word-wrap:break-word"><a href="http://hoelzle.org/publications/urs-thesis.pdf" target="_blank">http://hoelzle.org/publications/urs-thesis.pdf</a><div><br></div><div>Super. This looks great. Thank you for recommending it. </div></div></blockquote><div><br></div><div>That thesis is very good indeed. It explains the overall monomorphic and polymorphic inline cache logic.</div><div><br></div><div>However there are 2 main improvements in Cog&#39;s inline caches over the Self VM implementation described in Urs&#39; phd:</div>- Megamorphic sites uses a routine to search the method in a selector-based hash map instead of a self-modifying jump table</div><div class="gmail_quote">- Cog uses class tags for type tests.<div><br></div><div>There are other details, for example in Cog some send sites can be promoted early to megamorphic send sites.</div><div><br></div><div>These aspects are described in Eliot&#39;s post: <a href="http://www.mirandabanda.org/cogblog/2011/03/01/build-me-a-jit-as-fast-as-you-can/">http://www.mirandabanda.org/cogblog/2011/03/01/build-me-a-jit-as-fast-as-you-can/</a> .</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>Thanks,</div><div>Chris </div><div><br><div><blockquote type="cite"><div>On Mar 14, 2016, at 12:37 PM, stephane ducasse &lt;<a href="mailto:stephane.ducasse@gmail.com" target="_blank">stephane.ducasse@gmail.com</a>&gt; wrote:</div><br><div><div style="word-wrap:break-word">Hi chris<div><br></div><div>in the phd of Urs Holze there is a nice chapter explaining the cache and optimisation.</div><div>Worth reading it.</div><div><br></div><div>Stef</div><div><br><div><blockquote type="cite"><div>On 13 Mar 2016, at 19:42, Chris Cunnington &lt;<a href="mailto:brasspen@gmail.com" target="_blank">brasspen@gmail.com</a>&gt; wrote:</div><br><div><div style="word-wrap:break-word"><br><div><blockquote type="cite"><div>On Mar 13, 2016, at 2:14 PM, tim Rowledge &lt;<a href="mailto:tim@rowledge.org" target="_blank">tim@rowledge.org</a>&gt; wrote:</div><br><div><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">The clever bit is that the first part of the machine code we built for BoringClass&gt;theRubberPullets does a check that the class of the receiver is the same as the boringClassTag we loaded. If it is, no problem, carry on. If it is not then we abort to a routine that builds a PIC - a Polymorphic Inline Cache, see the 2nd URL above - moves things around a bit (not quite randomly) and once more rewrites the call so that now it jumps to the beginning of the PIC. And then we carry on again (isn’t that a neat title for a movie?) with  our processing.</span></div></blockquote></div><br><div>Right. This is the interesting part. But here’s the question: what’s different in an image from 5-7 years ago to an image now? Who is carrying this information? The receiver or the CompiledMethod? </div><div><br></div><div>The answer (as I understand it) is that the CompiledMethod is carrying a cue for the JIT. Something is going on there. The receiver doesn’t know anything, I don’t think. (I appreciate the process is going to ping it. But the process is not starting there.)</div><div><br></div><div>There’s been lots of talk about byte codes and new byte code set, but that’s not it. If I explore a CompiledMethod in an old image or a new one, it’s not going to show me when a PIC is activating. The header gets incinerated and replaced with machine code. And then there’s a check to see if the header is now machine code ash called #isCogMethodReference:. That is the bifurcation between the old way and the new. If Yes, then go to JIT related code. If No, then it looks like it always has. </div><div><br></div><div>Thank you for the links. I’ll check them out in a bit. I think I’m reaching saturation for now. </div><div><br></div><div>Chris </div></div></div></blockquote></div><br></div></div></div></blockquote></div><br></div></div><br></blockquote></div><br></div></div>