[Vm-dev] InterpreterSimulator

[stephane ducasse]

Hi chris

in the phd of Urs Holze there is a nice chapter explaining the cache and optimisation.
Worth reading it.

Stef

> On 13 Mar 2016, at 19:42, Chris Cunnington <brasspen at gmail.com> wrote:
> 
> 
>> On Mar 13, 2016, at 2:14 PM, tim Rowledge <tim at rowledge.org <mailto: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/20160314/379ea15d/attachment-0001.htm