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