<br><br><div class="gmail_quote">On Wed, Nov 19, 2008 at 12:13 PM, Gary Chambers <span dir="ltr">&lt;<a href="mailto:gazzaguru2@btinternet.com">gazzaguru2@btinternet.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
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...</blockquote><div><br></div><div>Doesn&#39;t really help. &nbsp;One wants the property to be of the receiver, not of the sending context. &nbsp;Inheritance gets in the way also since a subclass that overrides the setting would need to reimplement all methods that send class to get its own setting, and even then super sends could invoke inherited code compiled with the wrong setting. &nbsp;Alas this idea doesn&#39;t work.</div>
<div>&nbsp;</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
<br>
Regards, Gary.<br>
<br>
----- Original Message ----- From: &quot;Igor Stasenko&quot; &lt;<a href="mailto:siguctua@gmail.com" target="_blank">siguctua@gmail.com</a>&gt;<br>
To: &quot;The general-purpose Squeak developers list&quot; &lt;<a href="mailto:squeak-dev@lists.squeakfoundation.org" target="_blank">squeak-dev@lists.squeakfoundation.org</a>&gt;<br>
Sent: Wednesday, November 19, 2008 8:03 PM<br>
Subject: Re: [squeak-dev] Lightweight Classes<div><div></div><div class="Wj3C7c"><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2008/11/19 Eliot Miranda &lt;<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>&gt;:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
On Sun, Nov 16, 2008 at 7:11 PM, Igor Stasenko &lt;<a href="mailto:siguctua@gmail.com" target="_blank">siguctua@gmail.com</a>&gt; wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
2008/11/17 Hernán Morales Durand &lt;<a href="mailto:hernan.morales@gmail.com" target="_blank">hernan.morales@gmail.com</a>&gt;:<br>
&gt; Dear all,<br>
&gt; &nbsp; In the attachment you will find an implementation of Lightweight<br>
&gt; Classes<br>
&gt; for Squeak that follows the original paper &quot;Debugging Objects&quot; of &gt; Hinkle<br>
&gt; et<br>
&gt; al. However I was unable to set up the #class method in the<br>
&gt; LightweightClass<br>
&gt; to answer the real class of the lightwighted object, is this possible<br>
&gt; currently in Squeak?.<br>
&gt;<br>
&gt; What I did:<br>
&gt; -Created the LightweightClass as in the old VisualWorks &gt; implementation.<br>
&gt; The<br>
&gt; only difference here was CompiledMethod&#39;s cannot be copied, so I used<br>
&gt; #clone.<br>
&gt; -Created and installed an UnstoredMethod (a CompiledMethod subclass) &gt; in<br>
&gt; the<br>
&gt; LightweightClass&#39;s methodDictionary. Since I want to store the source<br>
&gt; code<br>
&gt; but not through the changes log, I borrowed the MethodWrappers idea of<br>
&gt; storing the state (sourceCode) in a class instance variable, and &gt; compile<br>
&gt; without logging. The methods I borrowed from MW are:<br>
&gt;<br>
&gt; -#copyWithTrailerBytes: - I think the superimplementor in &gt; CompiledMethod<br>
&gt; could use &quot;self class&quot; to avoid reimplementors.<br>
&gt; -#tweakClassFormat - which set the format but I don&#39;t know why and<br>
&gt; cannot<br>
&gt; find documentation on this.<br>
&gt; -#objectAt: I suspected the class literal was stored in the literal<br>
&gt; frame<br>
&gt; everytime I accepted a method, but for the simple test below still<br>
&gt; answer<br>
&gt; the LightweightClass and not the real class.<br>
&gt;<br>
&gt; Here is the test:<br>
&gt;<br>
&gt; | aDate |<br>
&gt; aDate := Date today.<br>
&gt; aDate becomeLightweight.<br>
&gt; aDate dispatchingClass compile: &#39;day ^43&#39; notifying: nil.<br>
&gt; aDate day. &quot; 43 (works) &quot;<br>
&gt; aDate perform: #class. &quot; Date ------&gt; (works) &quot;<br>
&gt; aDate class. &quot; {Date} ------&gt; LightweightClass (wrong) &quot;<br>
&gt;<br>
<br>
The only cause of this can be compiler.<br>
Instead of generating an instruction for sending #class message, it<br>
generates a bytecode to fetch the class from receiver oop , instead of<br>
sending real message.<br>
</blockquote>
<br>
IMO the bug is in the VM. &nbsp;The compiler generates bytecode 199, the special<br>
selector class send. &nbsp;But it is the VM that decides to short-cut this send<br>
and implement it by accessing the receiver&#39;s class directly instead of<br>
actually sending the message. &nbsp;I doubt very much this short-circuiting has<br>
any impact on performance (VisualWorks has never inlined this special<br>
selector send), and it is very easy to fix in the VM. &nbsp;A number of other<br>
special selector bytecodes become ordinary sends (e.g. next nextPut: etc).<br>
If class were important for performance one could implement something<br>
analogous to the at cache that speeds up at:, at:put: and size for special<br>
selectors. &nbsp;The special selector bytecode would check that the receiver of<br>
the class message had the standard implementation (primitive in Object) and<br>
answer the class directly. &nbsp;But this isn&#39;t going to save significant time.<br>
To fix this change<br>
bytecodePrimClass<br>
| rcvr |<br>
rcvr := self internalStackTop.<br>
self internalPop: 1 thenPush: (self fetchClassOf: rcvr).<br>
self fetchNextBytecode.<br>
to<br>
bytecodePrimClass<br>
messageSelector := self specialSelector: 23.<br>
argumentCount := 0.<br>
self normalSend.<br>
<br>
</blockquote>
<br>
Agreed, it seem a VM feature, kind of :)<br>
As &nbsp;temporary workaround, one could modify compiler to generate a<br>
normal send bytecode instead of using a short bytecode for special<br>
selector which #class is. I&#39;m not sure how easy/hard such modification<br>
could be made.<br>
<br>
And i agree, that such optimization buys a little. I didn&#39;t seen a<br>
code which does a heavy numerical crunching, where speed is essential,<br>
and at same time needs a #class sends. To my sense a #class appears in<br>
places where we need to deal with polymorphism or doing something on<br>
meta levels - but in such areas, a correctess is far more important<br>
than speed.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
&gt; Any hint would be appreciated.<br>
&gt; Best regards.<br>
&gt;<br>
&gt; Hernán<br>
&gt;<br>
&gt; PS: Just to avoid duplicate efforts, I wrote a LightweightClasses<br>
&gt; Browser<br>
&gt; which will be available as soon as I find a solution to the problem<br>
&gt; above.<br>
&gt;<br>
<br>
--<br>
Best regards,<br>
Igor Stasenko AKA sig.<br>
<br>
</blockquote></blockquote>
<br>
<br>
-- <br>
Best regards,<br>
Igor Stasenko AKA sig.<br>
<br>
</blockquote>
<br>
<br></div></div>
--------------------------------------------------------------------------------<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
</blockquote>
<br>
<br>
</blockquote></div><br>