[Vm-dev] [VM-dev] Does doesNotUnderstand:/cannotInterprer: jitted?

[Eliot Miranda]

Hi Denis,



_,,,^..^,,,_ (phone)
> On Nov 21, 2016, at 1:21 AM, Clément Bera <bera.clement at gmail.com> wrote:
> 
> 
> 
>> On Mon, Nov 21, 2016 at 10:10 AM, Denis Kudriashov <dionisiydk at gmail.com> wrote:
>>  
>> 
>> 2016-11-21 10:05 GMT+01:00 Clément Bera <bera.clement at gmail.com>:
>>> Hi.
>>> 
>>> #doesNotUnderstand: is added to the PIC. It's a special case handled for performance. DNUs are slower than normal sends but the overhead is acceptable.
>> 
>> But when it is in PIC it is not anymore slower? 
> 
> Well the DNU requires to create the message argument so it's always slower than normal call.

Right, bug it's very much faster than an uncached MNU.  In a VM that doesn't have the PUC optimization for MNU the following happens:
- the message being sent is looked up in the method lookup cache, and the lookup misses
- the message is searched for up the superclass chain all the way to Object and not found
- the Message is created
- doesNotUnderstand: is looked up in the method lookup cache, and the lookup succeeds

With the PIC optimization the above happens only on the first MNU send. Subsequently 
- the Message is created
- the relevant MNU method is invoked


You can measure the cost of a normal MNU in the stack vm which doesn't have PUCs and so can't optimise MNU


>>  Other VM call-backs are not added to PIC. In this case the VM is slower. But this is usually not present in production application.
>> 
>> Proxies could be based on it and used in production.
> 
> Right. Well then it's slower. 

But it's a lot faster than no PICs, or PUCs that don't record MNUs. :-)

>  
>> 
>> What about callback message when readonly objects is going to be modified? Is it jitted?
> 
>  This is done in a similar way to mustBeBoolean. The detection of read-only object instance variable mutation is jitted as part of the instance variable store, but if the call-back is actually triggered it's a bit slow. The call-back itself can be jitted too.

We could perhaps optimise this too; IIRC the receiver is always thisContext so the VM could cache that one lookup somewhere statically.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20161121/6ad53045/attachment.html>