[Pharo-project] [Vm-dev] Fwd: A question about lookup and message reification

Igor Stasenko siguctua at gmail.com
Wed Feb 13 23:24:08 UTC 2013


On 14 February 2013 01:04, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>
>
>
> On Wed, Feb 13, 2013 at 1:32 PM, Stéphane Ducasse <stephane.ducasse at inria.fr> wrote:
>>
>> Hi eliot
>>
>>> I repost the mail to the mailing-list since I do not see it in the vm-dev
>>
>>
>> did you post to vm-dev?
>>
>>
>> yes but since I'm travelling may be the mail was lost or I could not see appearing because one of my rules pushed it somewhere.
>> I changed machines and I have to get used to 10.8. My mail now decide to use the wrong account :(
>>
>>>
>>> Hi
>>>
>>> I was reading the following method in the VM code and I have a couple of questions:
>>>
>>> - I do not understand why lookupMethodInClass: may return a class. I was thinking that it would return a method.
>>
>>
>> It doesn't matter what it returns as it's return value is always ignored.
>>
>>
>> Ok I will read again the code. reading Slang is still nicer than plain generated C :)
>>
>> It assigns to newMethod.  I suspect it returns currentClass because a) the return type was always sqInt because Slang didn't support void functions, and b) currentClass is a value in hand so probably in a register and hence cheap to return.
>>
>>
>>
>> Ok
>> I was looking for an example to show a real lookup for the students that are implementing ObjVlisp
>> Now I will see if I show them this method.
>
>
> So just run an image with the simulator and stop at any of commonSend, internalFindNewMethod, lookupMethodInClass: and you'll see the call chain form the relevant send bytecode.
>
> Here's an expression that loads and runs an image with the StackInterpreter:
>
> | vm |
> StackInterpreter initializeWithOptions: (Dictionary newFromPairs: #()).
> vm := StackInterpreterSimulator new.
> vm openOn: '/Users/eliot/Squeak/Squeak4.4/trunk44.image'.
> vm openAsMorph; run
>
> and if you break on entry to internalFindNewMethod you'll see this stack:
>
> StackInterpreterSimulatorLSB(Object)>>break
> StackInterpreterSimulatorLSB(StackInterpreter)>>internalFindNewMethod
> StackInterpreterSimulatorLSB(StackInterpreterSimulator)>>internalFindNewMethod
> StackInterpreterSimulatorLSB(StackInterpreter)>>commonSend
> StackInterpreterSimulatorLSB(StackInterpreterSimulator)>>commonSend
> StackInterpreterSimulatorLSB(StackInterpreter)>>normalSend
> StackInterpreterSimulatorLSB(StackInterpreter)>>secondExtendedSendBytecode
> StackInterpreterSimulatorLSB(StackInterpreterSimulator)>>dispatchOn:in:
> StackInterpreterSimulatorLSB(StackInterpreterSimulator)>>run
> UndefinedObject>>DoIt
>
> If you find out what the selector is (e.g. self printOop: messageSelector) you can then use the simulator;s own breakpoint facilities:
>
> | vm |
> StackInterpreter initializeWithOptions: (Dictionary newFromPairs: #()).
> vm := StackInterpreterSimulator new.
> vm openOn: '/Users/eliot/Squeak/Squeak4.4/trunk44.image'.
> vm setBreakSelector: #&.
> vm openAsMorph; run
>
> and now it'll stop in sendBreak:point:receiver: and you'll get this stack:
>
> StackInterpreterSimulatorLSB(Object)>>halt:
> StackInterpreterSimulatorLSB(StackInterpreterSimulator)>>sendBreak:point:receiver:
> StackInterpreterSimulatorLSB(StackInterpreter)>>commonSend
> StackInterpreterSimulatorLSB(StackInterpreterSimulator)>>commonSend
> StackInterpreterSimulatorLSB(StackInterpreter)>>normalSend
> StackInterpreterSimulatorLSB(StackInterpreter)>>secondExtendedSendBytecode
> StackInterpreterSimulatorLSB(StackInterpreterSimulator)>>dispatchOn:in:
> StackInterpreterSimulatorLSB(StackInterpreterSimulator)>>run
> UndefinedObject>>DoIt
>>>
>>> - what is the invariant?
>>> that currentclass always point to the currently looked up class and
>>> newMethod is the found method?
>>
>>
>> The input arguments are messageSelector, argumentCount and its argument, class.  The VM suffers somewhat from being cluttered with global variables, which is I think a legacy of the blue-book specification (the Smalltalk code that was used to implement Interpreter in VMMaker) being derived from the Alto and Dorado implementations in microcode.  It would be nicer if there were fewer variables, but e.g. supplying argumentCount as a parameter throughout all the message handling routines can be difficult, especially when things like perform: and MNU change the argumentCount during message send.
>>
>>
>> I clearly see what you mean.
>>
>>> - why lookupMethodFor: selector InDictionary: dictionary is defined in StackInterpreter but never used
>>> only in CoInterpreter?
>>
>>
>> Well, it belongs in StackInterpreter and could be used in the other lookup methods.  I was probably considering rewriting the other lookup routines to use  lookupMethodFor: InDictionary: but didn't get round to it.
>>
>>
>> ok I see.
>>
>> While reading directly the see code I was wondering why you generate the ifdef for different bytecode set?
>> Is it that you would have to call another object and that it would not have the same instance variables.
>> Because I was thinking that such variation points could be handled by the different interpreter subclasses.
>
>
> Bytecode dispatch is performance-critical in the context and stack interpreters.  The ifdef means that if one is not using multiple bytecode sets dispatch is simpler and hence faster.
>
> Subclassing is very difficult because the simulators are not traits and so subclass each interpreter class.  hence adding a subclass to handle this difference means adding another simulator, and they're big and tedious to maintain.  IMO the multiple bytecode set work just isn't worth that kind of load.  The VM would be nicer if more fully decomposed.  I've done a fair amount (moving the objectMemory into an instance variable, putting the Cogit in its own class hierarchy, adding support for struct classes that define data types like a stack page or an abstract instruction or machine-code method in the JIT) but there's always more that one can do.
>

yes.. the amount of code in one class cries for decomposition..

but it would require serious investment of manhours .. which i assume
we will never have,
because there's always more important things to do.



-- 
Best regards,
Igor Stasenko.


More information about the Vm-dev mailing list