[Vm-dev] InterpreterSimulator

Clément Bera bera.clement at gmail.com
Tue Mar 15 16:36:47 UTC 2016


2016-03-15 15:32 GMT+01:00 Levente Uzonyi <leves at caesar.elte.hu>:

>
> On Tue, 15 Mar 2016, Clément Bera wrote:
>
> (no quote, sorry)
>
> I've been thinking about adaptive PICs as well, and I came up with a
> scheme which has the overhead of one comparison and one write per lookup
> plus some extra cost when some maintenance is necessary, but the amortized
> overhead is still constant. The memory overhead can be as low as 8 bytes
> per PIC.
> The scheme keeps track of the recently used branches, can detect and
> remove unused entries, reorder the branches based on recent usage, and even
> revert back to a CogMethod when there's only one entry left in the PIC.
> I took a look at the code in VMMaker, but it didn't seem trivial to
> implement and test it myself, so if there's interest, I will write the
> details. Or if someone can explain how to add a fewextra bytes to the PIC,
> I will give it a try again.
>
> I am interested. I have worked on many part of the JIT but not the PICs
directly, at the exception of the trampolines maybe. I am not sure I can
help myself, though if you have precise question I guess I could try to
answer.

Can you explain your PIC scheme ?

There are other problems related to PIC counters. For example the JIT will
need to differentiate PICs from normal and optimized methods to add the
counters or not. What could happen too is that machine code garbage
collection could reorder and transform PICs with counters to PICs without
counters. It's not obvious the performance gain of self-modifying PICs, it
has to be measured and if it's worth the complexity then we add it.


> Levente
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160315/bda5e3dd/attachment.htm


More information about the Vm-dev mailing list