I see at least one problem: at the point where we make a copy of a context, the closures that reference it are either in callees or not on the stack at all. Therefore we would need to take note of all the closures we meet on the way and update the outer contexts only if we find them on the stack. That makes copying a whole lot harder.
Max
Hi,
Is anybody aware of a reason for why Context>>copyTo: should not update the home of closures (which is currently the case)? This behaviour becomes a problem when I want to simulate #stepThrough: on a copied stack, since the home of a closure will never be found on the stack.
My proposal is to implement
Context>>postCopy closureOrNil ifNil: [ ^ self ].
closureOrNil outerContext: self
and
BlockClosure>>outerContext: aContext outerContext := aContext
Thoughts?
Cheers, Max
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.
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.
Alternatively, if you feel like it, you could try something like 'context becomeForward: copyOfContext'.
On Fri, Jun 3, 2016 at 11:02 AM, Max Leske maxleske@gmail.com wrote:
I see at least one problem: at the point where we make a copy of a context, the closures that reference it are either in callees or not on the stack at all. Therefore we would need to take note of all the closures we meet on the way and update the outer contexts only if we find them on the stack. That makes copying a whole lot harder.
Max
Hi,
Is anybody aware of a reason for why Context>>copyTo: should not update
the home of closures (which is currently the case)? This behaviour becomes a problem when I want to simulate #stepThrough: on a copied stack, since the home of a closure will never be found on the stack.
My proposal is to implement
Context>>postCopy closureOrNil ifNil: [ ^ self ].
closureOrNil outerContext: selfand
BlockClosure>>outerContext: aContext outerContext := aContext
Thoughts?
Cheers, Max
On 03 Jun 2016, at 12:30, Clément Bera bera.clement@gmail.com wrote:
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.
On Fri, Jun 3, 2016 at 11:02 AM, Max Leske <maxleske@gmail.com mailto:maxleske@gmail.com> wrote:
I see at least one problem: at the point where we make a copy of a context, the closures that reference it are either in callees or not on the stack at all. Therefore we would need to take note of all the closures we meet on the way and update the outer contexts only if we find them on the stack. That makes copying a whole lot harder.
Max
Hi,
Is anybody aware of a reason for why Context>>copyTo: should not update the home of closures (which is currently the case)? This behaviour becomes a problem when I want to simulate #stepThrough: on a copied stack, since the home of a closure will never be found on the stack.
My proposal is to implement
Context>>postCopy closureOrNil ifNil: [ ^ self ].
closureOrNil outerContext: selfand
BlockClosure>>outerContext: aContext outerContext := aContext
Thoughts?
Cheers, Max
vm-dev@lists.squeakfoundation.org
-
Clément Bera -
Max Leske