On Mon, Nov 17, 2008 at 4:11 PM, Igor Stasenko <siguctua at gmail.com> wrote:

>
>
> The only cause of this can be compiler.
> Instead of generating an instruction for sending #class message, it
> generates a bytecode to fetch the class from receiver oop , instead of
> sending real message.
>

Yes, the Compiler and Smalltalk bytecode set is doing this. I need this
change too at some stage, so I've spent some time on it.

See this:
http://users.ipa.net/~dwighth/smalltalk/bluebook/bluebook_chapter28.html

The send bytecode in question is decimal 199. This pushes the receiver's
class on the stack, no questions asked.

I've looked at modifying the compiler, but I'm finding it to be a daunting
piece of software.

The send bytecode is written to the compiled method stream in
SelectorNode>>emit:args:on:super: at the top of the method as a "short
send".

The SelectorNode instance is initialised as a shared class variable called
"StdSelectors" in VariableNode>>initialize. As you can see there, its values
are retrieved from the SystemDictionary. Once initialised as a class
variable, it is again copied in Encoder>>initScopeAndLiteralTables.

So the special selectors array lives in the SystemDictionary's special
objects array in slot 24, meaning that the VM also refers to these
selectors. I'm not sure why the VM wants them.

As with fixing this, I guess that replacing the value in the special
selectors array and then running VariableNode>>initialize might do the
trick. Or it might crash the VM.

Gulik.

-- 
http://people.squeakfoundation.org/person/mikevdg
http://gulik.pbwiki.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20081120/0762fd18/attachment.htm