[Pharo-project] [squeak-dev] Re: Issue with traits

Eliot Miranda eliot.miranda at gmail.com
Thu Oct 22 16:51:34 UTC 2009


On Wed, Oct 21, 2009 at 1:28 PM, Ken.Dickey <Ken.Dickey at whidbey.com> wrote:

> Why not share the code?  Just use a "cell" to hold the class and have
> methodClass accessor do the indirection.
>

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?

There are several objections to this, which are a matter of taste (yer makes
yer choice and yer pays yer price)

- 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.

- 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.

- 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).

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.

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.

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.

I would simply duplicate trait methods containing super sends and start
using Newspeak when stable and fast implementations become available.


If you have a bit in the method header, the VM could use it as a 0/1 index
> into the code to call to do (or not do) the extra indirection.  Just think
> of
> the a trait method as a closure which is parameterized on the class.
>

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)

Am I missing something deep here?
>

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.


> -KenD
>

best
Eliot


>
> > Message: 7
> > Date: Wed, 21 Oct 2009 09:41:08 +0200
> > From: Adrian Lienhard <adi at netstyle.ch>
> > Subject: Re: [Pharo-project] [squeak-dev] Re: Issue with traits
> > To: The general-purpose Squeak developers list
> >         <squeak-dev at lists.squeakfoundation.org>,        Pharo
> Development
> >         <pharo-project at lists.gforge.inria.fr>
> > Message-ID: <3C7E5C51-21A8-483A-81A0-40854430A43B at netstyle.ch>
> > Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
> >
> > I've fixed this issue in Pharo a couple of months ago. CompiledMethods
> > are not shared anymore, so methodClass returns the expected class. At
> > the time I implemented traits (2004?), there were no method properties
> > and hence sharing compiled methods worked -- of course except for
> > super sends in which case the method was always recompiled (so the
> > answer to Andreas' question below is b)).
> >
> > Cheers,
> > Adrian
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20091022/bc9468bf/attachment.htm


More information about the Squeak-dev mailing list