The system keeps dependency information to keep track of the fact that the machine code for bar depends on b being a data slot. During the _Define:, bar's code is marked as "outdated", and it's stack frame is marked. When control returns to bar (after the change), a trap handler is invoked which recompiles bar before continuing execution.

It seems to me that depending on what the compiler has inlined, and how it moved code around and optimized some of it away, that it isn't easy to continue execution after recompiling a method. I haven't had time to think this through, but the new compilation of the method might organize its stack/registers differently. Just remapping the instruction pointer from the old method to the new seems quite complicated.

I realize that you must have all this worked out already on the old Self just to be able to dump the stack correctly considering all the tricks the compiler might play. The OOPSLA'89 paper mentions scope description and bytecode mappings as the solution. How much overhead do you get for keeping all that information. Would it be too costly to throw it away and, when you need it, to recompile the old version of the method to regenerate all this?

-- Jecel

P.S.: I hope my last message didn't cause any confusion - I copied the date to try to make it clear I was referring to an old message.