[Vm-dev] [VM-dev] Does reflective call (#perform:) jitted?

Clément Bera bera.clement at gmail.com
Wed Nov 23 07:04:15 UTC 2016


On Wed, Nov 23, 2016 at 12:51 AM, Eliot Miranda <eliot.miranda at gmail.com>
wrote:

>
> Hi Denis,
>
> On Tue, Nov 22, 2016 at 12:05 PM, Denis Kudriashov <dionisiydk at gmail.com>
> wrote:
>
>>
>> Hello.
>>
>> I have another question on special cases for jitter.
>>
>> Do VM has a kind of PIC for reflective calls like #perform:?
>>
>
> No.  The perform: primitive is in machine code and probes the first-level
> method lookup cache.  If it finds a hit it either jumps to the entry point
> (if the method is fitted) or enters the interpreter (if the method is
> not).  The issue here is that the cache needs to be at the send site, but
> there is nothing special about the #perform:[with:*] selector. Whether the
> send is a perform or not depends on the send binding to a method containing
> as perform: primitive.
>
> In addition to receiver class it could also check selector from argument.
>>
>
> What exactly do you mean here?
>

Hi,

I think he's talking about Stefan Marr optimisation. For perform, you could
have a first inline cache at send site, and when finding the perform
primitive, instead of relinking to the machine code of perform, it would
create a second PIC-like cache which compares again already met selectors
and directly dispatch to the method to be performed. It would move perform
cache from a global cache in the primitive to per send site caches,
speeding up perform. In addition, the Sista optimiser could read the
selector information.


> _,,,^..^,,,_
> best, Eliot
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20161123/aa24ac1c/attachment-0001.html>


More information about the Vm-dev mailing list