Well - I'm finally here (that's another post). Now, I'm trying to pay attention to Markus' talk on bytecode x-forms. What he's done is implement a library (Squeak) called ByteSurgeon. It provides a high level API, and should be portable. So... why muck at the bytecode level?

• No need to change the VM
• No source needed
• Other languages are possible
• Performance - no need to change any sources or worry about decompilation

The idea - simple API:

Instrument: [:instruction | InstrCounter increase].

InstrCounter reset

InstrumentSend: [instruction | InstrCounter increase].

What about transforming bytecode? There's #insertBefore:, #insertAfter, #replace: It's easy to see how those are useful for debugging and method wrappering - in fact, the VW debugger uses bytecode insertion in order to add breakpoints. It's also a simple way to add in no cost (at runtime, not at dev time) logging.

What about accessing various pieces of useful state? meta variables to access receiver, arguments, result, etc.

InstrumentSend: [:s | m insertAfter: 'Logger logSendTo: <meta: #receiver>].

That opens up a number of possibilities. The nifty thing (at least for Squeak and VW) is that the Smalltalk level compiler is accessible, and you can jump in and insert additional steps at the AST level (which is what Markus is talking about). Using ByteSurgeon to create Method Wrappers - 40 lines of code, not much slower on execution (5x). Simple MOP achieved.

At least in Squeak, using ByteSurgeon is faster than whole method compilation (2x faster than the optimized Squeak compiler).

Futures?

• AST vs Bytecode
• Gepetto MOP
• Omniscient Debugger