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

[Denis Kudriashov]

2016-11-23 8:04 GMT+01:00 Clément Bera <bera.clement at gmail.com>:

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

Yes, exactly.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20161123/43a37284/attachment.html>