What should be in the next release.

[Bryce Kampjes]

Tony Garnock-Jones writes:
 > Bryce Kampjes wrote:
 > > The big question is whether to work on blocks next.
 > 
 > Yes please! I'm looking forward to throwing away the compiler hacks that
 > inline ifTrue:ifFalse: and friends.

At the moment, I'm only talking about compiling methods that create
blocks. Full method (and block) inlining is planned but later. It's
a very nice optimisation but not needed to make Exupery useful. It'll
make it much more useful though.

 > > It will also make the Exupery shutdown code more
 > > important because an unmodified VM will not understand these new
 > > context objects and require image support code to deal with compiled
 > > contexts (say for debugging).
 > 
 > That's very interesting. Are you going to pursue a Self-style
 > revert-to-simpler-representations-on-demand strategy?

I already deconvert contexts when shutting down or restarting Exupery.
But that only means clearing out the native code program counter
stored in the method context's spare slot. Contexts need to be
deconverted before clearing the code cache, otherwise there'll be
dangling pointers to machine code no longer there which causes amusing
bugs.

With ExuperyContext's I'll need to create normal interpreter contexts
when deconverting the contexts.  That should happen on demand to allow
single stepping in the debugger.

With full method inlining it'll need to un-inline like Self but I have
no plans to have a stack cache like VisualWorks or Self (I think)
because hopefully inlining will remove enough send overhead.

 > > The top four items are:
 > >  * blocks
 > >  * super sends
 > >  * new
 > >  * integration (making primitive inlining usable and the 
 > > 	        the profiling compiler effective)
 > 
 > What's different about super sends as compared to regular sends? Isn't
 > the statically-available information better for super sends, and
 > otherwise they're more-or-less the same? (What am I missing? I should
 > perhaps have my morning coffee.)

Super sends are basically the same as normal sends except the lookup
starts with the super class. Lookup is done by Slang support code at
the moment. Exupery can't compile them yet but they should be fairly
easy to add.

 > I'd vote for blocks, new, integration, super-sends to be the order.

I'll probably do blocks, super-sends, then new with integration work
scattered between them. But I'll re-evaluate after doing whatever's
first. Blocks are the most work (probably as much as everything else)
and the most risky.

The decisions are driven by profiling. Not being able to compile
methods with blocks stops the most methods from being compiled,
then it's not being able to compile super sends. After that each
cause only has a small benefit. Object creation shows up a lot
in profiles.

The two problems I see when compiling real programs with Exupery are
it can't compile enough methods so execution in stays compiled code
for long enough and object creation is slow. Blocks and super sends
will allow almost all normal methods to be compiled.

Sends between compiled code and interpreted code are about as fast
as normal interpreted calls so in send heavy code it's vital to stay
in compiled code for most sends if compiling is going to provide a
speed improvement.

Bryce