--- Dan Sugalski <[EMAIL PROTECTED]> wrote: > On Sun, 14 Sep 2003, Gordon Henriksen wrote: > > > On Saturday, September 13, 2003, at 11:33 , [EMAIL PROTECTED] > > > wrote: > > > > > On Sat, 13 Sep 2003, Luke Palmer wrote: > > > > > > Of course having a "no subclasses" tag means the compiler can > change a > > > method call into a direct subroutine call, but I would hope that > method > > > calling will be fast enough that it won't need to. > > > > A strategy to actually keep that optimization, and apply it to much > more > > code, would be that the JIT compiler could optimize for the case > that > > there are no known subclasses, and pessimize that only if a > subclass > > were later loaded. > > > > I think this is one of the features Leo's been on about with > respect to > > notifications. > > That's one of the reasons notifications were designed in, yes. > 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? =Austin
