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:m.rueger@acm.orgm.rueger@acm.org> 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, 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 siguctua@gmail.com wrote:

2009/5/6 Eliot Miranda eliot.miranda@gmail.com:

...

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.