Context>>copyTo: doesn't update closure home

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Context>>copyTo: doesn't update closure home

Max Leske
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

Reply | Threaded
Open this post in threaded view
|

Re: [Vm-dev] Context>>copyTo: doesn't update closure home

Clément Béra
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 <[hidden email]> 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: self
>
> and
>
> BlockClosure>>outerContext: aContext
>       outerContext := aContext
>
>
> Thoughts?
>
> Cheers,
> Max

Reply | Threaded
Open this post in threaded view
|

Re: [Vm-dev] Context>>copyTo: doesn't update closure home

Max Leske

On 03 Jun 2016, at 12:30, Clément Bera <[hidden email]> 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 <[hidden email]> 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: self
>
> and
>
> BlockClosure>>outerContext: aContext
>       outerContext := aContext
>
>
> Thoughts?
>
> Cheers,
> Max