[Vm-dev] InterpreterSimulator

[Clément Bera]

2016-03-14 18:08 GMT+01:00 Chris Cunnington <brasspen at gmail.com>:

>
> http://hoelzle.org/publications/urs-thesis.pdf
>
> Super. This looks great. Thank you for recommending it.
>

That thesis is very good indeed. It explains the overall monomorphic and
polymorphic inline cache logic.

However there are 2 main improvements in Cog's inline caches over the Self
VM implementation described in Urs' phd:
- Megamorphic sites uses a routine to search the method in a selector-based
hash map instead of a self-modifying jump table
- Cog uses class tags for type tests.

There are other details, for example in Cog some send sites can be promoted
early to megamorphic send sites.

These aspects are described in Eliot's post:
http://www.mirandabanda.org/cogblog/2011/03/01/build-me-a-jit-as-fast-as-you-can/
.


> Thanks,
> Chris
>
> On Mar 14, 2016, at 12:37 PM, stephane ducasse <stephane.ducasse at gmail.com>
> wrote:
>
> 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> 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/93df6a0a/attachment-0001.htm