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.