Progress towards Exupery 0.12

[bryce at kampjes.demon.co.uk]

J J writes:
 > >From: <bryce at kampjes.demon.co.uk>
 > >The problem with arithmetic primitives is
 > >they're already manually inlined. The SmallInteger inlining needs to
 > >be moved to use a generic primitive inlining mechanism.
 > 
 > Won't the Exupery image disable all Squeak inlining (at least in later 
 > versions)?  I would expect it too, since the profiling code will cause 
 > Exupery to quickly inline anything Squeak would inline itself anyway, no?

Exupery will not disable Squeak's current inlining. Exupery works
from bytecodes, Squeak inlines when generating bytecodes. Exupery
needs passable interpreted performance to compile the first few
methods. Exupery's story tests clear out Exuperys code cache before
each test to ensure that the test is only testing the intended
compiled code.

That said, I'd expect that with Exupery, many of the inlinings done
now would be removed just not ifTrue: and whileTrue: and friends.
And I'm sure some people will want to remove ifTrue: and whileTrue:
from their images to allow for easier experimentation.

Having decent interpreted performance is nice even with dynamic
inlining. It'll take dynamic inlining some time to figure out what
should be inlined and there are a handful of places where Exupery can
not be used. Even with dynamic inlining interpreted performance will
matter for the first few minutes or on machines without an Exupery
port.

Bryce