The three things that have been added since the last release are: * More x86 addressing modes * Generic primitives (calling out to the interpreter's primitives) * Eliot's closure bytecodes and Freetype support merged into the VM
More x86 addressing modes and generic primitives have helped out with performance.
The addressing modes help out in send/return code which accesses VM variables. Previously the address of the variable had to be loaded into a register, then that used to access it. Now it can be done in a single instruction.
Generic primitive support improves the number of cases Exupery can increase performance. If a primitive is called now that Exupery doesn't know how to compile, it can now dispatch to it via a PIC which is much faster than running through the interpreters lookup code.
Eliot's closure bytecodes have been merged in because the Pharo developers would like to start using them. I'd like to see proper closure support. At the moment the VM will run closure code but Exupery will not be able to compile it. That will take another VM change, and an Exupery compiler change to free up the "unused" slot in MethodContext.
The subpixel changes to bitblt have been merged into the VM, and the exupery-dev project on the Universes modified to load the packages required to build the FreeType plugin. I've got makefiles that work, they're not ideal but I ran into autoconf/automake issues that prevented using a better solution.
Also, I think I know what one of the remaining bugs is. When returning into compiled code from interpreted code the compiled context is not being marked as a root. Contexts are real objects, and need to keep the garbage collector book-keeping. Any objects in old space must be marked as roots if they point to new space. To avoid write barrier checks on context writes (all stack operations, and temporary assignments), all contexts are marked as roots if they're in old space when they're entered. Exupery's code does the marking in the return bytecode because there are less returns than points to return to. Every send, or potential send has an entry point, which is much more than the number of return bytecodes.
Next, I'll investigate this potential bug then fix it if it's real.
Bryce