[Vm-dev] InterpreterSimulator

[Chris Cunnington]

> On Mar 14, 2016, at 1:32 PM, tim Rowledge <tim at rowledge.org> wrote:
> 
> 
> 
>> On 13-03-2016, at 11:42 AM, Chris Cunnington <brasspen at gmail.com> wrote:
>> 
>> 
>>> On Mar 13, 2016, at 2:14 PM, tim Rowledge <tim at rowledge.org> wrote:
>>> 
>>> The clever bit is that the first part of the machine code we built for BoringClass>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.
>> 
>> 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? 
> 
> To a first approximation the image knows nothing about this - hence our ability to run the same images on non-Cog VMs. All the clever stuff is carried in the code cache where machine code routines are written as we translate.

It’s impressive to me that the addition to the JIT is this subtle. At the same time it has made it harder for me to grasp it. I’ve felt that it was like quantum theory, it’s everywhere, but you have no way of comprehending it. 
> 
>> 
>> The answer (as I understand it) is that the CompiledMethod is carrying a cue for the JIT. Something is going on there.
> 
> The one exception is that we molest the CompiledMethod object’s method header instvar when we do a translation.

To me, this is the Rosetta Stone of understanding Cog and the JIT. I think that this would be the place to start for anybody trying to understand the JIT. If a CM gets called enough times, then it’s header becomes machine code. Subsequent requests are routed to the speedier code. 

That’s something a person like myself can get a grip on. From there, questions can be asked to contextualize that single, solid observation: How many times until the transition?; What is doing the watching?; Where do things get routed once the transition is made?; etc. 

> This allows the translated machine code to know some stuff and rather more importantly means we can tell if a method has a translated doppelganger when we do a lookup. We can get away with this because the header of a CM is only accessed from the image-side via a primitive, which can thus test to see if it needs to go to a translated method to get the real value or not.

Yowza. That is subtle. The header is the sole point of contact between the image world and JIT-world.
 
Thanks, 
Chris 

> 
> 
> 
>> 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.)
> 
> Indeed. The receiver is from Barcelona.
> 
> The weird thing about all this is that the basics are really simple if explained clearly, but the details can be … tricky.
> 
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> Useful random insult:- Got into the gene pool while the lifeguard wasn't watching.
> 
>