[squeak-dev] Lightweight Classes

Gary Chambers gazzaguru2 at btinternet.com
Wed Nov 19 20:13:26 UTC 2008


Perhaps the compiler could ask the class (or meta) of the method being 
compiled as to whether to inline a selector. All after the fact until a full 
recompile of the class, of course...

Regards, Gary.

----- Original Message ----- 
From: "Igor Stasenko" <siguctua at gmail.com>
To: "The general-purpose Squeak developers list" 
<squeak-dev at lists.squeakfoundation.org>
Sent: Wednesday, November 19, 2008 8:03 PM
Subject: Re: [squeak-dev] Lightweight Classes


> 2008/11/19 Eliot Miranda <eliot.miranda at gmail.com>:
>>
>>
>> On Sun, Nov 16, 2008 at 7:11 PM, Igor Stasenko <siguctua at gmail.com> 
>> wrote:
>>>
>>> 2008/11/17 Hernán Morales Durand <hernan.morales at gmail.com>:
>>> > Dear all,
>>> >   In the attachment you will find an implementation of Lightweight
>>> > Classes
>>> > for Squeak that follows the original paper "Debugging Objects" of 
>>> > Hinkle
>>> > et
>>> > al. However I was unable to set up the #class method in the
>>> > LightweightClass
>>> > to answer the real class of the lightwighted object, is this possible
>>> > currently in Squeak?.
>>> >
>>> > What I did:
>>> > -Created the LightweightClass as in the old VisualWorks 
>>> > implementation.
>>> > The
>>> > only difference here was CompiledMethod's cannot be copied, so I used
>>> > #clone.
>>> > -Created and installed an UnstoredMethod (a CompiledMethod subclass) 
>>> > in
>>> > the
>>> > LightweightClass's methodDictionary. Since I want to store the source
>>> > code
>>> > but not through the changes log, I borrowed the MethodWrappers idea of
>>> > storing the state (sourceCode) in a class instance variable, and 
>>> > compile
>>> > without logging. The methods I borrowed from MW are:
>>> >
>>> > -#copyWithTrailerBytes: - I think the superimplementor in 
>>> > CompiledMethod
>>> > could use "self class" to avoid reimplementors.
>>> > -#tweakClassFormat - which set the format but I don't know why and
>>> > cannot
>>> > find documentation on this.
>>> > -#objectAt: I suspected the class literal was stored in the literal
>>> > frame
>>> > everytime I accepted a method, but for the simple test below still
>>> > answer
>>> > the LightweightClass and not the real class.
>>> >
>>> > Here is the test:
>>> >
>>> > | aDate |
>>> > aDate := Date today.
>>> > aDate becomeLightweight.
>>> > aDate dispatchingClass compile: 'day ^43' notifying: nil.
>>> > aDate day. " 43 (works) "
>>> > aDate perform: #class. " Date ------> (works) "
>>> > aDate class. " {Date} ------> LightweightClass (wrong) "
>>> >
>>>
>>> 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.
>>
>> IMO the bug is in the VM.  The compiler generates bytecode 199, the 
>> special
>> selector class send.  But it is the VM that decides to short-cut this 
>> send
>> and implement it by accessing the receiver's class directly instead of
>> actually sending the message.  I doubt very much this short-circuiting 
>> has
>> any impact on performance (VisualWorks has never inlined this special
>> selector send), and it is very easy to fix in the VM.  A number of other
>> special selector bytecodes become ordinary sends (e.g. next nextPut: 
>> etc).
>> If class were important for performance one could implement something
>> analogous to the at cache that speeds up at:, at:put: and size for 
>> special
>> selectors.  The special selector bytecode would check that the receiver 
>> of
>> the class message had the standard implementation (primitive in Object) 
>> and
>> answer the class directly.  But this isn't going to save significant 
>> time.
>> To fix this change
>> bytecodePrimClass
>> | rcvr |
>> rcvr := self internalStackTop.
>> self internalPop: 1 thenPush: (self fetchClassOf: rcvr).
>> self fetchNextBytecode.
>> to
>> bytecodePrimClass
>> messageSelector := self specialSelector: 23.
>> argumentCount := 0.
>> self normalSend.
>>
>
> Agreed, it seem a VM feature, kind of :)
> As  temporary workaround, one could modify compiler to generate a
> normal send bytecode instead of using a short bytecode for special
> selector which #class is. I'm not sure how easy/hard such modification
> could be made.
>
> And i agree, that such optimization buys a little. I didn't seen a
> code which does a heavy numerical crunching, where speed is essential,
> and at same time needs a #class sends. To my sense a #class appears in
> places where we need to deal with polymorphism or doing something on
> meta levels - but in such areas, a correctess is far more important
> than speed.
>
>>> > Any hint would be appreciated.
>>> > Best regards.
>>> >
>>> > Hernán
>>> >
>>> > PS: Just to avoid duplicate efforts, I wrote a LightweightClasses
>>> > Browser
>>> > which will be available as soon as I find a solution to the problem
>>> > above.
>>> >
>>>
>>> --
>>> Best regards,
>>> Igor Stasenko AKA sig.
>>>
>
>
> -- 
> Best regards,
> Igor Stasenko AKA sig.
>


--------------------------------------------------------------------------------


>
> 




More information about the Squeak-dev mailing list