[Vm-dev] Re: [Pharo-dev] Proxy DNU vs CannotInterpret. (Ghost related)

Mariano Martinez Peck marianopeck at gmail.com
Mon Feb 15 19:49:49 UTC 2016


On Mon, Feb 15, 2016 at 4:46 PM, Clément Bera <bera.clement at gmail.com>
wrote:

>
>
>
> 2016-02-15 19:34 GMT+01:00 Eliot Miranda <eliot.miranda at gmail.com>:
>
>>
>> Hi Stef,
>>
>> On Mon, Feb 15, 2016 at 8:18 AM, stepharo <stepharo at free.fr> wrote:
>>
>>> Hi eliot
>>>
>>> I think that the difference is really what guillermo explained.
>>> With DNU you can only trapped methods that are not defined while if you
>>> want to implement true proxy you do not want holes.
>>> I think that also with DNU proxy there were some limits realyed to
>>> classe but I do not remember.
>>>
>>
>> As far as the VM goes, there is /one/ minor issue with special selector
>> #== and #class (*).  But the real issue is that ProtoObject implements far
>> too much protocol.  If one creates a class that inherits from nil all it
>> needs to do is implement doersNotUnderstand: and it will catch every
>> message (*).  For this to work the debugger and basic inspectors must use
>> the mirror primitives otherwise there will be infinite recursion of MNUs.
>>
>> Now the issue with special selector #== and #class is that these
>> bytecodes are specified as no lookup.  So if one uses bytecodes 182 (#==)
>> or 199 (#class) these operate without sending messages and will compare the
>> object or answer the object's class without sending #doesNotUnderstand:.
>>
>> In the VW VM I added a flag so one could turn this behaviour off, and
>> that's certainly easy to do in our VM.  Another approach is to have the
>> bytecode compiler not send these.
>>
>> But given our VM it is certainly possible to use doesNotUnderstand:
>> proxies, using a much slimmer class than ProtoObject.  In fact a good
>> project would be to try and shrink ProtoObject until it provides the
>> minimum, which would be a #doesNotUnderstand: method that raises an error
>> that reminds the programmer that they need to implement their own
>> doesNotUnderstand: handler in subclasses of ProtoObject.
>>
>>
> Hello,
>
> The #class primitive bytecode is not used in Pharo to avoid this kind of
> problem.
>
> It is indeed possible to add a setting in Opal compiler not to compile #==
> using the inlined selector to avoid issues there too. However, even in
> proxies, it may make sense to have this inlined selector.
>
>
>
When I made Ghost, Pharo still using the inlined version of #class. So when
loading Ghost I used to hack on Opal to avoid optimizing  #class. At that
time, I did a bench and it showed me that remove the optimization had
almost none penalization at all. And in fact, in future Pharo released this
ended up being removed.

Cheers,



>
>
>
>
>>
>>> Stef
>>>
>>> Le 15/2/16 16:06, Eliot Miranda a écrit :
>>>
>>> Hi Denis,
>>>
>>> On Feb 15, 2016, at 6:53 AM, Denis Kudriashov < <dionisiydk at gmail.com>
>>> dionisiydk at gmail.com> wrote:
>>>
>>>
>>> 2016-02-15 15:32 GMT+01:00 Mariano Martinez Peck <
>>> <marianopeck at gmail.com>marianopeck at gmail.com>:
>>>
>>>> As far as I can remember (this was about 4 years ago) The use of
>>>> #cannotInterpret: was the only way to be able to intercept everything
>>>> without breaking the system. Subclassing from ProtoObject make your proxy
>>>> to understand some messages. Subclassing from nil was technically possible,
>>>> but I found out the system would simply crash as it didn't know at all how
>>>> to handle other subclasses of nil. Even with the debugging support I added
>>>> as you can read in the paper. Maybe things have changed.
>>>>
>>>> If subclassing from nil does not break the system and you can still
>>>> inspect, debug proxies, then sure, you can give a try to Ghost using #dnu
>>>> rather than #cannotInterpret:. In fact, I would like to have a dnu-based
>>>> approeach that is as reliable as it was #cannotInterpret: in the sense of
>>>> how much I can intercept. With #cannotInterpret I could trap EVERYTHING
>>>> (everything but #==) and then decide what to do. Subclassing from nil would
>>>> get you there too if you make it work.
>>>>
>>>
>>> Actually I already implemented it many yeas ago for Mocketry. But
>>> subclassing from nil works correctly only in VW. I got problems when
>>> porting it to Squeak (at that time).
>>> Now I want to give DNU another chance. It will simplify logic very much.
>>> It will remove strange hierarchy of proxies which is needed for trick but
>>> raises many questions.
>>>
>>>
>>> There is no reason in principle why Squeak/Pharo should not be able to
>>> use MNU proxies in the same way as VW.  The key is to use the mirror
>>> primitives in basic inspectors that are used to inspect the proxies and
>>> in the debugger to simulate code.  Without the mirror primitives many
>>> sends to a proxy are likely to create an infinite recursion.  As yet we
>>> don't have a robust low space handler that catches infinite recursion so
>>> debugging can be frustrating.  But we can work on this.  IMO the MNU
>>> approach is to be preferred.
>>>
>>>
>>>
>>
>>
>> --
>> _,,,^..^,,,_
>> best, Eliot
>>
>>
>
>


-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160215/9dad6c5a/attachment.htm


More information about the Vm-dev mailing list