anObject acting as aCompiledMethod
Alejandro F. Reimondo
aleReimondo at sugarweb.com
Thu Mar 23 23:49:00 UTC 2000
Thanks, for your answer, but it sounds like a hacking technique
for me (yes, 100%Smalltalk, but a hack :).
I feel that adopting the mechanism as a "basical behaviour" in Smalltalk
(as #doesNotUnderstand:) has the benefit that do not alert the reader
(hiding the real sourcecode can be difficult to debug).
Another problem that I found is that the lookUp is not done
by the VM (loosing speed) and the methods implementing the
lookup can't be patched that way.
I have been working in a transfer mechanism to build
small sized images (image seeds that grow eating methods
& classes dynamically from a parent image through a comm channel).
I am thinking in the replacement of all (possible) methods
by ONLY ONE object (to save image space).
I have implemented a replacement method that uses
the current context to find receiver,message & arguments;
the problem can be solved this way; but I think that it is not
a "clean" implementation. (nothing more clear that not to
implement it, like when handling #doesNotUnderstand:).
If we adopt a clear & explicit way to handle the problem
of notACompiledMethod for a selector, the idea
can be propagated to other Smalltalk providers...
Also we will solve the crash of VM for malformed method dictionaries,
because they can be debugged.
Now the VM crash and all the objects dead immediately.
De: Eric Arseneau[SMTP:eat at huv.com]
Responder a: squeak at cs.uiuc.edu
Enviado el: Jueves 23 de Marzo de 2000 00:31
Para: squeak at cs.uiuc.edu
Asunto: RE: anObject acting as aCompiledMethod
You can do the same thing that you are asking for without having to revert
to changing the VM.
Here is a possible way to do it. It has the cost of an extra lookup to find
the "real" method, but the plus side is that it is done in Smalltalk where
it can be controlled much more easily. Here goes
1) Create a subclass of compiled method, call it ProxyCompiledMethod
2) This new class has the result of compiling something like:
(self methodLookupMechanism findMethodForSelector: #proxyMethod object:
3) Note that the above can be built to handle any number of args. Also
performOn: is probably not correct, but something like it would work.
Somebody help here
4) Override the sourceString method to return the appropriate source you
would like to see, instead of the above source. This way the user sees the
correct code and no tools need to be changed.
5) Override the compile mechanism, the class is asked for it's compiler.
Make it do whatever is appropriate, build a method object managed by
something else and keep it.
6) Your done
I know the explanation is not as detailed as could be, but I hope you can
get the idea. The point is that there is enough power there to change the
behavior the way you would like. The hard part is changing the true method
lookup of a class, which has been talked about before. It would be cool to
be able to change the method lookup mechanism of an object from with
Smalltalk. Whether this is really practical or not is another issue. But I
believe that the above gives you something appropriate.
Hope this helps ...
NOTE: I used this trick to get my Java VM, written in VA Smalltalk, to do
this to handle interfaces. I also use a method name mangling technique
which is not too original, but works. I'm hoping to port the VM to Squeak
as soon as I can get some time and release it.
From: Alejandro F. Reimondo [mailto:aleReimondo at sugarweb.com]
Sent: Wednesday, March 22, 2000 11:14 AM
To: 'Squeak List'
Subject: anObject acting as aCompiledMethod
As long as I know, we actually do not have a mechanism
like #doesNotUnderstand: but for compiled methods...
When the message lookup success, the found compiled
method is not checked by the VM as a real CompiledMethod
instance. The VM assumes that the method is aCompiledMethod
and activates a context...
If the found object is not aCompiledMethod, the VM crashes. :^(
Placing a little check when a method is found can be used
to trigger a mechanism that send a "normal" message
to the found method to evaluate.
1.- VM lookUp for a method capable of solve the
message to (aReceiver,selector,arguments)
2.- if the found method aCompiledMethod
isA: CompiledMethod => normal activation
3.- if not a CompiledMethod then the VM can
send message #evaluate: (or #value:) to the "compiledMethod"
with aFullMessage (aReceiver,selector, arguments)
as the argument
The implementation of a mechanism like this can be used
to implement method wrappers or "proxyMethods".
This mechanism can be used to replace all the methods
of a class with ONE object (the same object for all selectors)
that load the methods from a server or from a parent image
Also we can implement pseudoMethods that can:
x returns always anObject
x return results of evaluating them (like one-argument blocks)
x activates a context in an alternate virtual machine (with diferent
x forward the message to a remote VM
hope that it can be interesting to implement behavior wrappers
and metaprogramming tools.
More information about the Squeak-dev