What are mirror primitives?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

What are mirror primitives?

Chris Muller-4
In going through all of the package versions for the 4.2
release-notes, I came across this:

--------------
Name: Kernel-eem.501
Author: eem
Time: 25 September 2010, 7:55:34.708 pm
UUID: 5b55eae3-594b-4416-9d47-5a4ebaabb238
Ancestors: Kernel-ul.500

Add mirror primitives which can be used for accurate
execution simulation (a.k.a. debugging) of proxies.
---------------

One of the things that concerns Magma applications are instances of
its own proxies being sent as an argument to a primitive.  I'm able to
rectify most cases with a simple #yourself to the argument in the
_sender_ (unfortunately I cannot do it in the top of the primitive
method itself, which would be ideal).

It's an unfortunate piercing of the transparency and so this made me
wonder whether there isn't a more general solution to this problem to
handle all cases.

 - Chris

Reply | Threaded
Open this post in threaded view
|

Re: What are mirror primitives?

Eliot Miranda-2
Hi Chris,

the mirror primitives are basic object access and testing primitives that take the objects they operate upon as arguments.  Compare these with the basic object access and testing primitives that operate on their receiver:

ContextPart>>#object:basicAt: Object>>#basicAt:
ContextPart>>#object:basicAt:put: Object>>#basicAt:put:
ContextPart>>#object:eqeq: Object>>#==
ContextPart>>#object:instVarAt: Object>>#instVarAt:
ContextPart>>#object:instVarAt:put: Object>>#instVarAt:put:
ContextPart>>#object:perform:withArguments:inClass: Object>>#perform:withArguments:inClass:
ContextPart>>#objectClass: Object>>#class
ContextPart>>#objectSize: Object>>#basicSize

The execution machinery needs just these primitives to simulate bytecodes correctly (it needs to use primitives in the VM to evaluate primitives in general).  If the execution simulation machinery /doesn't/ use these primitives and uses the Object ones instead then code involving proxies will not simulate correctly because instead of operating on the receiver they may be forwarded to some other object through a doesNotUnderstand: implementation.  e.g.  if you have some instance of a class that doesn't understand any messages, say a forwarder, and you try and simulate execution, then any attempt to access an inst var of the instance via instVarAt: is doomed to fail and will access the inst var of the object being forwarded to, rendering the debugger useless for debugging proxies.  If the system uses the mirror primitives on the other hand simulation is correct because these primitives operate on their arguments instead of their receiver and so in being sent to a context they are always received as intended.

As soon as the standard VM implements these primitives correctly we can upgrade the execution simulation machinery in ContextPart and MethodContext to use them.  We've been using these at Teleplace for quite a while now, and they've been in VisualWorks for a long time.

But as I understand your issue with Magma I don't think these solve your problem.  Instead I guess all you'd need is to wrap all your primitives and put the send of yourself in the wrappers.

HTH
Eliot


On Thu, Dec 23, 2010 at 12:51 PM, Chris Muller <[hidden email]> wrote:
In going through all of the package versions for the 4.2
release-notes, I came across this:

--------------
Name: Kernel-eem.501
Author: eem
Time: 25 September 2010, 7:55:34.708 pm
UUID: 5b55eae3-594b-4416-9d47-5a4ebaabb238
Ancestors: Kernel-ul.500

Add mirror primitives which can be used for accurate
execution simulation (a.k.a. debugging) of proxies.
---------------

One of the things that concerns Magma applications are instances of
its own proxies being sent as an argument to a primitive.  I'm able to
rectify most cases with a simple #yourself to the argument in the
_sender_ (unfortunately I cannot do it in the top of the primitive
method itself, which would be ideal).

It's an unfortunate piercing of the transparency and so this made me
wonder whether there isn't a more general solution to this problem to
handle all cases.

 - Chris




Reply | Threaded
Open this post in threaded view
|

Re: What are mirror primitives?

Chris Muller-3
Great explanation, thank you.

On Thu, Dec 23, 2010 at 3:33 PM, Eliot Miranda <[hidden email]> wrote:

> Hi Chris,
> the mirror primitives are basic object access and testing primitives that
> take the objects they operate upon as arguments.  Compare these with the
> basic object access and testing primitives that operate on their receiver:
> ContextPart>>#object:basicAt: Object>>#basicAt:
> ContextPart>>#object:basicAt:put: Object>>#basicAt:put:
> ContextPart>>#object:eqeq: Object>>#==
> ContextPart>>#object:instVarAt: Object>>#instVarAt:
> ContextPart>>#object:instVarAt:put: Object>>#instVarAt:put:
> ContextPart>>#object:perform:withArguments:inClass:
> Object>>#perform:withArguments:inClass:
> ContextPart>>#objectClass: Object>>#class
> ContextPart>>#objectSize: Object>>#basicSize
> The execution machinery needs just these primitives to simulate bytecodes
> correctly (it needs to use primitives in the VM to evaluate primitives in
> general).  If the execution simulation machinery /doesn't/ use these
> primitives and uses the Object ones instead then code involving proxies will
> not simulate correctly because instead of operating on the receiver they may
> be forwarded to some other object through a doesNotUnderstand:
> implementation.  e.g.  if you have some instance of a class that doesn't
> understand any messages, say a forwarder, and you try and simulate
> execution, then any attempt to access an inst var of the instance via
> instVarAt: is doomed to fail and will access the inst var of the object
> being forwarded to, rendering the debugger useless for debugging proxies.
>  If the system uses the mirror primitives on the other hand simulation is
> correct because these primitives operate on their arguments instead of their
> receiver and so in being sent to a context they are always received as
> intended.
> As soon as the standard VM implements these primitives correctly we can
> upgrade the execution simulation machinery in ContextPart and MethodContext
> to use them.  We've been using these at Teleplace for quite a while now, and
> they've been in VisualWorks for a long time.
> But as I understand your issue with Magma I don't think these solve your
> problem.  Instead I guess all you'd need is to wrap all your primitives and
> put the send of yourself in the wrappers.
> HTH
> Eliot
>
> On Thu, Dec 23, 2010 at 12:51 PM, Chris Muller <[hidden email]> wrote:
>>
>> In going through all of the package versions for the 4.2
>> release-notes, I came across this:
>>
>> --------------
>> Name: Kernel-eem.501
>> Author: eem
>> Time: 25 September 2010, 7:55:34.708 pm
>> UUID: 5b55eae3-594b-4416-9d47-5a4ebaabb238
>> Ancestors: Kernel-ul.500
>>
>> Add mirror primitives which can be used for accurate
>> execution simulation (a.k.a. debugging) of proxies.
>> ---------------
>>
>> One of the things that concerns Magma applications are instances of
>> its own proxies being sent as an argument to a primitive.  I'm able to
>> rectify most cases with a simple #yourself to the argument in the
>> _sender_ (unfortunately I cannot do it in the top of the primitive
>> method itself, which would be ideal).
>>
>> It's an unfortunate piercing of the transparency and so this made me
>> wonder whether there isn't a more general solution to this problem to
>> handle all cases.
>>
>>  - Chris
>>
>
>
>
>
>