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.


> 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.
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20081119/8754d076/attachment.htm