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

[Eliot Miranda]

Hi Denis, Hi Clément,

> On Nov 23, 2016, at 1:01 AM, Denis Kudriashov <dionisiydk at gmail.com> wrote:
> 
> 
> 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. 

I see.  That adds another path to linking send sites (first invocation of a jitted perform: or when linking a send site checking for a perform target), and to unblinking send sites on cache flush.  But it's eminently doable.  I wonder if we have any volunteers willing to take a look or whether it should get added to mine and Clément's lists (which are quite full).  Denis, do you have any idea of the kinds of overhead due to perform you have in meaningful benchmarks?  My guess is it's a very small part of total overhead.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20161123/0b615cb1/attachment.html>