Exupery send optimisation plans
Last updated at 12:46 pm UTC on 17 January 2006
Sends are the current area being worked on.
Things to do for send optimisation:
- DONE Remove the identity dictionary look up for returns. This could be done by storing the return address in the unused message slot. Exupery Return Optimisation
- DONE Basic PIC support. At this point compiled code should be significantly faster than interpreted code for sends. Exupery Send Optimisation
- (The 0.05 release)
- DONE Return to the right place in the compiled method rather than to the beginning. This will remove the current if then else checks done when entering methods. Returns should then cost a single branch mispredict.
- Specialise sends for each different receiver. This is needed both to have specialised primitives for at: and at:put and also for inlining methods.
- Add method inlining.
- Add block support.
I don't think that blocks will provide much benefit until after inlining has been added. Most common uses of blocks have already been inlined by the bytecode compiler. Adding them early just creates more code to maintain, they should be very similar to sends so there aren't really any new concepts for the compiler.
There is one problem with adding blocks: where to store the return address. There's an empty field in MethodContexts but there isn't one in BlockContexts. I can think of two solutions, either create new compiled context objects or use a context cache. The context cache could contain extra values.
The key thing to think about with BlockContexts is to try and use the same machinery that inlined methods will use. Creating new compiled context objects is a nice way to introduce inlined methods. The interpreter would need to be extended to handle unexpected contexts but it could send a message to the context which could decompile it if needed. I don't know how exceptions fit into all of this.