Colin Putney writes:
 > However, peering into the future a bit, I imagine that taking advantage 
 > of Exupery would also require image format changes of one kind or 
 > another (eg, I'd love to see a class called NativeMethod). So some 
 > questions are in order: Do we want to try to avoid two image format 
 > changes in a short amount of time? Will Exupery require or benefit from 
 > an image format change? Is Exupery progressing quickly enough that this 
 > is even an issue?

Exupery requires no image format changes. The code is kept in a
separate memory block, this is important because the memory needs to
be executable which requires special allocation. Currently it's
possible to execute a method partially with compiled code and
partially with the interpreter. I'd like to keep this ability because
it means I can flush the code cache at any time. Also debugger support
is trivial.

Exupery will require a few extra system classes. I suspect that a
CompiledContext class will be needed to support multiple methods.  The
problem is recognising a native method when execution returns back
into it from another method. Calling a compiled method is easier
because the methodCache can be used to hide compiled method lookup.

The only nice short term thing would be to get the block closure
support in. That's only to avoid dealing with block contexts twice.

In the medium term the only reasons to change the image format are to
speed up things other than execution. Speeding up some parts of the
system makes others look slow. For instance if bytecode execution was
10 times faster then the garbage collector would take 50% of execution
time.

I wouldn't expect any such changes for the next year. Any such changes
could probably be hidden by the image loading and saving code anyway.

So no, image changes are not an issue for Exupery.

Bryce