<br><br><div class="gmail_quote">On Wed, Oct 21, 2009 at 1:28 PM, Ken.Dickey <span dir="ltr"><<a href="mailto:Ken.Dickey@whidbey.com">Ken.Dickey@whidbey.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Why not share the code? Just use a "cell" to hold the class and have<br>
methodClass accessor do the indirection.<br></blockquote><div><br></div><div>The methodClass is used to identify the owning class for the purposes of super sends. IIUC, your approach would have each class reference a method with a pair, containing a backpointer to the class and a forward pointer to the method, right?</div>
<div><br></div><div>There are several objections to this, which are a matter of taste (yer makes yer choice and yer pays yer price)</div><div><br></div><div>- there is space overhead. Every compiled method requires an additional two slot object. That's about 800k in a 20 Meg image. I just went through the effort of eliminating MethodProperties for most compiled methods in my closure compiler.</div>
<div><br></div><div>- without a JIT there is time overhead. The pair has to be part of the VM state for the VM to access the class through it. Either the VM has to maintain two objects (the closure and the method) on each send/return or it has to maintain the closure and pay an extra indirection on every access to the method's literals.</div>
<div><br></div><div>- with a JIT there is the complexity of having the JIT manage copying the method on a per-class basis so it can inline the closure's class reference (for methods containing super sends). Again possible, and even to be preferred if one is approaching adaptive optimization in a particular way. ut it is not an approach I've taken in Cog (BrouHaHa did this, VW did not. I like to keep things simple and not do it. become and changeClass are complicated by doing it).</div>
<div><br></div><div>But there is another approach which is taken by Newspeak. There's a paper on it and its a little complicated; too complicated for me to go into the gory details here. But the idea is essentially to have the VM cope with two separate hierarchies, the mixin hierarchy that exists to hold code, and the class hierarchy (actually a forrest) created at runtime to run code. Essentially at run-time a module containing mixins is instantiated to create a class hierarchy.</div>
<div><br></div><div>An instance is an instance of a class, as ever. But a class has a slot referencing the mixin from which it was created. The method lives in the mixin, and the method's methodClass points to the mixin. A super send involves walking the receiver's class hierarchy to find the class whose mixin slot matches the method's methodClass/methodMixin. The super send can then proceed from that class, which may be a superclass of the receiver's class.</div>
<div><br></div><div>Newspeak also requires special support for lexically-scoped implicit receiver sends, which again involve walking the two hierarchies to orient a send correctly. Luckily all of Newspeak's special sends are amenable to inline cacheing, so only an interpreter pays a significant cost. However, I think you can see that supporting this is non-trvial. One has to reconfigure the class system to implement proper mixins, and provide new bytecode support, or at least new semantics for super sends.</div>
<div><br></div><div>I would simply duplicate trait methods containing super sends and start using Newspeak when stable and fast implementations become available.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
If you have a bit in the method header, the VM could use it as a 0/1 index<br>
into the code to call to do (or not do) the extra indirection. Just think of<br>
the a trait method as a closure which is parameterized on the class.<br></blockquote><div><br></div><div>This has similar objections. Having the VM in two states depending on the bit is expensive (in the limit one ends up wth two interpreters) and the bit still needs testing at least on each frame-building send. Again a JIT can change the equation. But this is non-trivial work for questionable benefit (sharing those methods which contain super sends and are provided through traits)</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Am I missing something deep here?<br></blockquote><div><br></div><div>No. As ever, its a small matter of programing. As Travis Griggs is fond of saying, 10 small words: if it is to be, it is up to me.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
-KenD<br></blockquote><div><br></div><div>best</div><div>Eliot</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
> Message: 7<br>
> Date: Wed, 21 Oct 2009 09:41:08 +0200<br>
> From: Adrian Lienhard <<a href="mailto:adi@netstyle.ch">adi@netstyle.ch</a>><br>
> Subject: Re: [Pharo-project] [squeak-dev] Re: Issue with traits<br>
> To: The general-purpose Squeak developers list<br>
> <<a href="mailto:squeak-dev@lists.squeakfoundation.org">squeak-dev@lists.squeakfoundation.org</a>>, Pharo Development<br>
> <<a href="mailto:pharo-project@lists.gforge.inria.fr">pharo-project@lists.gforge.inria.fr</a>><br>
> Message-ID: <<a href="mailto:3C7E5C51-21A8-483A-81A0-40854430A43B@netstyle.ch">3C7E5C51-21A8-483A-81A0-40854430A43B@netstyle.ch</a>><br>
> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes<br>
><br>
> I've fixed this issue in Pharo a couple of months ago. CompiledMethods <br>
> are not shared anymore, so methodClass returns the expected class. At <br>
> the time I implemented traits (2004?), there were no method properties <br>
> and hence sharing compiled methods worked -- of course except for <br>
> super sends in which case the method was always recompiled (so the <br>
> answer to Andreas' question below is b)).<br>
><br>
> Cheers,<br>
> Adrian<br>
<br>
</blockquote></div><br>