Austin Hastings <[EMAIL PROTECTED]> writes: >> There's a growing body of interesting work on what's essentially >> disposable or partially-useful optimizations. Given the dynamic >> nature of most of the languages we care about for parrot, throwaway >> optimizations make a lot of sense--we can build optimized versions >> of functions for the current structure, and redo them if the >> structure changes. >> >> This isn't entirely an easy task, however, since you can't throw >> away or redo a function/method/sub/whatever that you're already in >> somewhere in the call-chain, which means any optimizations will >> have to be either checked at runtime or undoable when code is in >> the middle of them. > > Why is this? > > Given that threads are present, and given the continuation based > nature of the interpreter, I assume that code blocks can be > closured. So why not allocate JITed methods on the heap and manage > them as first class closures, so that the stackref will hold them > until the stack exits?
Ooh, cunning.
