Ideas for CompiledMethod proxies?

On Tue, 30 Nov 2010, Igor Stasenko wrote:

.. and then you need to change #do: , #associationsDo: etc etc..

Or he can subclass MethodDictionary and override those methods.


Levente

Thanks to both for answering me.
Now, I have very very newbie question.
In my case, JUST BECAUSE i am testing, I directly access the CompiledMethod using MethodDictionary >> #at:ifAbsent:
thus, I can intercept and load back the original proxy.

Now, if I understood well, when you send a simple message to an object, the method lookup is done at VM side, and there is no call to MethodDictionary >> #at:ifAbsent:

So, what I am saying is that someone (the system) can send messages to a SmallInteger that acts as a compiled methods, without accessing it by MethodDictionary >> #at:ifAbsent:.
If that message is understood by the SmallInetger, then it will probably answer something different than the original method.

Now, maybe what I am thinking cannot happen.

Thanks once again

Mariano

On Tue, Nov 30, 2010 at 10:23 PM, Levente Uzonyi <[hidden email]> wrote:

On Tue, 30 Nov 2010, Igor Stasenko wrote:

.. and then you need to change #do: , #associationsDo: etc etc..

Or he can subclass MethodDictionary and override those methods.


Levente

On Tue, Nov 30, 2010 at 2:33 PM, Mariano Martinez Peck <[hidden email]> wrote:

Thanks to both for answering me.
Now, I have very very newbie question.
In my case, JUST BECAUSE i am testing, I directly access the CompiledMethod using MethodDictionary >> #at:ifAbsent:
thus, I can intercept and load back the original proxy.

Now, if I understood well, when you send a simple message to an object, the method lookup is done at VM side, and there is no call to MethodDictionary >> #at:ifAbsent:

So, what I am saying is that someone (the system) can send messages to a SmallInteger that acts as a compiled methods, without accessing it by MethodDictionary >> #at:ifAbsent:.
If that message is understood by the SmallInetger, then it will probably answer something different than the original method.

You're forgetting that the VM executes the methods it finds in a method dictionary, except if the VM finds other than a CompiledMethod in a method dictionary, in which case it sends run:with:in: to it.  So the VM won't send anything to the SmallInteger method proxy other than run:with:in:.  If it didn't send run:with:in: it would crash trying to execute the SmallInteger.

best

Eliot

Now, maybe what I am thinking cannot happen.

Thanks once again

Mariano

On Tue, Nov 30, 2010 at 10:23 PM, Levente Uzonyi <[hidden email]> wrote:

On Tue, 30 Nov 2010, Igor Stasenko wrote:

.. and then you need to change #do: , #associationsDo: etc etc..

Or he can subclass MethodDictionary and override those methods.


Levente

On Tue, Nov 30, 2010 at 11:45 PM, Eliot Miranda <[hidden email]> wrote:

On Tue, Nov 30, 2010 at 2:33 PM, Mariano Martinez Peck <[hidden email]> wrote:

Thanks to both for answering me.
Now, I have very very newbie question.
In my case, JUST BECAUSE i am testing, I directly access the CompiledMethod using MethodDictionary >> #at:ifAbsent:
thus, I can intercept and load back the original proxy.

Now, if I understood well, when you send a simple message to an object, the method lookup is done at VM side, and there is no call to MethodDictionary >> #at:ifAbsent:

So, what I am saying is that someone (the system) can send messages to a SmallInteger that acts as a compiled methods, without accessing it by MethodDictionary >> #at:ifAbsent:.
If that message is understood by the SmallInetger, then it will probably answer something different than the original method.

You're forgetting that the VM executes the methods it finds in a method dictionary, except if the VM finds other than a CompiledMethod in a method dictionary, in which case it sends run:with:in: to it.  So the VM won't send anything to the SmallInteger method proxy other than run:with:in:.  If it didn't send run:with:in: it would crash trying to execute the SmallInteger.

I think we are confusing exatly like we were confusing yesterday with my supervisors.

Eliot, one thing is to do this:

MyClass methodDict at: #foo put: 5.

MyClass new foo.

Here I am SURE the VM will send #run:with:in to SmallInteger.

Now, my question is when I send a MESSAGE to the CompiledMethod, and NOT to the object which class has installed the compiled method.

Suppose I do:  (MyClass methodDict at: #foo) size.   and that I don't change the implementation of MethodDictionary >> #at:ifAbsent:

In this case, the VM will just try to send the message size to that whatever is there. Both, SmallInteger and CompiledMethod understand #size, but both answer different things...
I cannot intercept this, and I cannot load back the original object.

This is why with Levento we thought about modifying MethodDictionary >> #at:ifAbsent:  to something like this:

at: key ifAbsent: aBlock

    | index value |
    index := self findElementOrNil: key.
    (self basicAt: index) == nil ifTrue: [ ^ aBlock value ].
    value := array at: index.

    (value mareaIsProxy) ifTrue: [value mareaUninstall].
    ^ array at: index


But then, my question is if the system may access by another way than that one. Ok, I should also modify some other methods in MethodDictionary like #valuesDo:  etc,,,
but if I do that, is that enough?   or the system can still send messages without passing there?

Thanks a lot!

mariano



 

best

Eliot

Now, maybe what I am thinking cannot happen.

Thanks once again

Mariano

On Tue, Nov 30, 2010 at 10:23 PM, Levente Uzonyi <[hidden email]> wrote:

On Tue, 30 Nov 2010, Igor Stasenko wrote:

.. and then you need to change #do: , #associationsDo: etc etc..

Or he can subclass MethodDictionary and override those methods.


Levente