sq 3.9 compiledmethod #sourceClass and #methodClass

Andrew Tween amtween at hotmail.com
Tue Oct 10 09:31:54 UTC 2006


Hi,
.snip...
> For Traits, this now leads to undefined results, as did #who before.
> This should be fixed, of course. There are three alternatives: 1)
> allways return the Trait on
> #methodClass, 2) give up CompiledMethod sharing alltogether or 3)
> have CompiledMethods be real Objects and share the ByteCode ByteArray
> and the literals.
>
> So.. best would be 3), but this seems to be off for at least 8 other
> years, so I guess it would be 1) first and later maybe 2, as the
> CompiledMethod sharing makes
> not much sense as soon as CompiledMethods know something about where
> they are in the system.

Method sharing, appears to me, to be an optimization (of memory/ image size)
which causes some problems. I wonder how much space is actually saved by this
sharing, are any numbers available?

I also wonder about up-and-coming technologies like Exupery & Spoon, and whether
they would have any problems with shared CompiledMethods.

There is also the Traits-with-state / Stateful Traits research (which I haven't
had time to look into). Can anyone comment on whether that will require, or
prohibit, method sharing?

My preference would be for option 2 - give up method sharing. Then all trait
methods are treated in a consistent manner and the problems with sharing are
avoided, albeit at the expense of increased image size/ memory usage.

Option 3 also sounds good - I shall ponder it over the next 8 years ;)
Cheers,
Andy




More information about the Squeak-dev mailing list