Here's a list if things that could be considered for 0.16 in rough
priority order:
1) Full method inlining
2) Support for proper closures
3) Tuning to make the current compiler more useful
4) Saving the image without removing all native code
5) Saving native code with the image
I've fairly much settled on 1) as the main part of the
next release. It'll change the overall behaviour of Exupery
so it's worth doing before focusing on tuning the profiler
to pick the correct hot-spots. It's also hard to judge the
value of other send optimisations until I can see how well
dynamic inlining works.
2) would be nice and isn't that large. It'll involve freeing up the
"unused" slot in MethodContext, Exupery uses it as a flag to indicate
what methods are compiled and what methods are interpreted. That's a
legacy from back when it was the native PC. After freeing up the
"unused" slot closure support is just implementing a few more
bytecodes.
3) was the original plan. As reliability has jumped up enough to
tackle full method inlining and relative send performance is so much
worse on Core 2 than it was on Athlon 1) looks more appealing.
4) and 5) will both make testing a little easier. Given Exupery
is a slow compiler it shouldn't really throw native code away
as readily as it does now. Being able to use native code for longer
will add significantly to the practicality of Exupery but the driver
at this stage is making long tests easier to perform.
At this stage, I'd guess 0.16 will have 1) and possibly 2). Full
method inlining is a fairly big task made up of various stages.
Inlining methods that don't create blocks is much simpler than
inlining methods that do refer to blocks.
Bryce
_______________________________________________
Exupery mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery
Locked
