[Vm-dev] InterpreterSimulator

[Chris Cunnington]

> 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? 

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.)

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. 

Thank you for the links. I’ll check them out in a bit. I think I’m reaching saturation for now. 

Chris 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160313/0717eada/attachment.htm