Smalltalk › Squeak › Squeak VM

callbacks and Cog

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

8 messages Options

Eliot Miranda-2

callbacks and Cog

Hi All,

I'm canvassing for some opinions on callback support in Cog. The underlying implementation issue is that while a callback is in progress, (execution has reentered Smalltalk) the generated machine-code zone may be compacted (because new Smalltalk methods are being compiled) which will move the site of the original callout and cause a crash unless something is done about it. The "something to do about it" is to have a slightly more expensive call in the first place such that the return path of the callout doesn't come back through the machine code following the call but through some other piece of code that figures out the right thing to do. So there is a small but significant penalty for primitive calls in which callbacks can happen which is more noticeable the quicker the code called is.

I would rather not pay this performance penalty for every external primitive call and only pay it for FFI calls. Is this restriction reasonable? i.e. is it OK for the VM to refuse to accept callbacks in the context of vanilla named plugin primitive calls?

best

Eliot

Michael Rueger-6

Re: callbacks and Cog

Eliot Miranda wrote:

> I would rather not pay this performance penalty for every external
> primitive call and only pay it for FFI calls. Is this restriction
> reasonable? i.e. is it OK for the VM to refuse to accept callbacks in
> the context of vanilla named plugin primitive calls?

this might be a naive suggestion, but couldn't you -or rather the plugin
author- tag primitve calls that do callbacks and generate a different
calling sequence?

Michael

Andreas.Raab

Re: callbacks and Cog

In reply to this post by Eliot Miranda-2

Eliot Miranda wrote:
> I would rather not pay this performance penalty for every external
> primitive call and only pay it for FFI calls. Is this restriction
> reasonable? i.e. is it OK for the VM to refuse to accept callbacks in
> the context of vanilla named plugin primitive calls?

It's not. Our current use case invokes callbacks from a named primitive,
not an FFI call. Let's talk about this later.

Cheers,
- Andreas

Eliot Miranda-2

Re: callbacks and Cog

In reply to this post by Michael Rueger-6

On Wed, May 6, 2009 at 8:51 AM, Michael Rueger <[hidden email]> wrote:

Eliot Miranda wrote:

I would rather not pay this performance penalty for every external primitive call and only pay it for FFI calls. Is this restriction reasonable? i.e. is it OK for the VM to refuse to accept callbacks in the context of vanilla named plugin primitive calls?

this might be a naive suggestion, but couldn't you -or rather the plugin author- tag primitve calls that do callbacks and generate a different calling sequence?

Michael

In the future yes. But I have to support existing plugins now. From Andreas' response it looks like all external calls will pay the slight extra price. No biggie, but I needed to know :)

thanks all.

Ken G. Brown

Re: callbacks and Cog

How about selling the Mac version of Canvas to someone who cares?
Ken

At 9:19 AM -0700 5/6/09, Eliot Miranda apparently wrote:

>On Wed, May 6, 2009 at 8:51 AM, Michael Rueger <<mailto:[hidden email]>[hidden email]> wrote:
>
>
>Eliot Miranda wrote:
>
>I would rather not pay this performance penalty for every external primitive call and only pay it for FFI calls. Is this restriction reasonable? i.e. is it OK for the VM to refuse to accept callbacks in the context of vanilla named plugin primitive calls?
>
>
>this might be a naive suggestion, but couldn't you -or rather the plugin author- tag primitve calls that do callbacks and generate a different calling sequence?
>
>Michael
>
>
>In the future yes. But I have to support existing plugins now. From Andreas' response it looks like all external calls will pay the slight extra price. No biggie, but I needed to know :)
>
>thanks all.

Ken G. Brown

Re: callbacks and Cog

Doh! Undo, undo...
Forgive me, email sent in total error...

Ken

At 10:36 AM -0600 5/6/09, Ken G. Brown apparently wrote:

>
>How about selling the Mac version of Canvas to someone who cares?
> Ken
>
>At 9:19 AM -0700 5/6/09, Eliot Miranda apparently wrote:
>>On Wed, May 6, 2009 at 8:51 AM, Michael Rueger <<mailto:[hidden email]>[hidden email]> wrote:
>>
>>
>>Eliot Miranda wrote:
>>
>>I would rather not pay this performance penalty for every external primitive call and only pay it for FFI calls. Is this restriction reasonable? i.e. is it OK for the VM to refuse to accept callbacks in the context of vanilla named plugin primitive calls?
>>
>>
>>this might be a naive suggestion, but couldn't you -or rather the plugin author- tag primitve calls that do callbacks and generate a different calling sequence?
>>
>>Michael
>>
>>
>>In the future yes. But I have to support existing plugins now. From Andreas' response it looks like all external calls will pay the slight extra price. No biggie, but I needed to know :)
>>
>>thanks all.

Igor Stasenko

Re: callbacks and Cog

In reply to this post by Eliot Miranda-2

2009/5/6 Eliot Miranda <[hidden email]>:
>
> Hi All,
> I'm canvassing for some opinions on callback support in Cog. The underlying implementation issue is that while a callback is in progress, (execution has reentered Smalltalk) the generated machine-code zone may be compacted (because new Smalltalk methods are being compiled) which will move the site of the original callout and cause a crash unless something is done about it. The "something to do about it" is to have a slightly more expensive call in the first place such that the return path of the callout doesn't come back through the machine code following the call but through some other piece of code that figures out the right thing to do. So there is a small but significant penalty for primitive calls in which callbacks can happen which is more noticeable the quicker the code called is.
> I would rather not pay this performance penalty for every external primitive call and only pay it for FFI calls. Is this restriction reasonable? i.e. is it OK for the VM to refuse to accept callbacks in the context of vanilla named plugin primitive calls?

I don't know how this can be applied to Cog, but you could use a
simple indirection, when returning from callback - instead of pushing
a direct return address (by using call CPU instruction), use a
continuation-style call, like:

1. pushRemappableOop(mycallInfo).
2. jump to procedure which is statically compiled (in C) , which
a) reenters the interpreter, and
b) upon return does popRemappableOop, read the return address from
there and then jumps to that address.

of course, push/pop remappable oop can be replaced by something else,
which could help you to deal with relocation.
> best
> Eliot
>

--
Best regards,
Igor Stasenko AKA sig.

Eliot Miranda-2

Re: callbacks and Cog

Igor,

great minds think alike!! This is *exactly* the solution I had in mind and am currently implementing. The cost of the mechanism over the conventional call is essentially zero because one s simply substituting a return address (ok, so two instructions, push constant, jump, instead of one call). However in the code one returns to there is a little extra work. It must extract the argument count from newMethod (the callback mechanism correctly maintains newMethod) to cut-back the stack on success, and on failure it must decide whether to enter machine code (if newMethod is compiled) or the interpreter (if it isn't).

On Wed, May 6, 2009 at 10:20 AM, Igor Stasenko <[hidden email]> wrote:

2009/5/6 Eliot Miranda <[hidden email]>:

>
> Hi All,
> I'm canvassing for some opinions on callback support in Cog. The underlying implementation issue is that while a callback is in progress, (execution has reentered Smalltalk) the generated machine-code zone may be compacted (because new Smalltalk methods are being compiled) which will move the site of the original callout and cause a crash unless something is done about it. The "something to do about it" is to have a slightly more expensive call in the first place such that the return path of the callout doesn't come back through the machine code following the call but through some other piece of code that figures out the right thing to do. So there is a small but significant penalty for primitive calls in which callbacks can happen which is more noticeable the quicker the code called is.
> I would rather not pay this performance penalty for every external primitive call and only pay it for FFI calls. Is this restriction reasonable? i.e. is it OK for the VM to refuse to accept callbacks in the context of vanilla named plugin primitive calls?

I don't know how this can be applied to Cog, but you could use a
simple indirection, when returning from callback - instead of pushing
a direct return address (by using call CPU instruction), use a
continuation-style call, like:

1. pushRemappableOop(mycallInfo).
2. jump to procedure which is statically compiled (in C) , which
a) reenters the interpreter, and
b) upon return does popRemappableOop, read the return address from
there and then jumps to that address.

of course, push/pop remappable oop can be replaced by something else,
which could help you to deal with relocation.
> best
> Eliot
>

--
Best regards,
Igor Stasenko AKA sig.