The way I understand it the closure is shared between the original and the copied stack. If you change the closure outerContext to match the copied context, then non local returns / debugging won't work any more on the original stack.
That���s true, I didn���t think of that.
As you mentioned, updating all the closures referencing the context as their outer context is non trivial. I believe you can do it lazily (at least that's my conclusion from the sista experience where I need to do that if the outer context is deoptimized). The only cases where the outerContext is used are non local returns and debugging. If a non local return fails, it calls the #cannotReturn: call-back. You can change the code there to do the right think if the outer context is not correct (like setting the correct outer context and retrying the non local return). You can also change the BlockClosure code to check at each outerContext in-image read if the outerContext is valid or not. I think that's much better than updating ahead of time all the closure instances.
I think I���ll have to do something like this, yes.
Alternatively, if you feel like it, you could try something like 'context becomeForward: copyOfContext���.
No, I don���t want to risk anything. Although it probably wouldn���t hurt in most cases.
Thanks Cl��ment.