[Vm-dev] callbacks and Cog

Igor Stasenko siguctua at gmail.com
Wed May 6 17:20:34 UTC 2009


2009/5/6 Eliot Miranda <eliot.miranda at 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.


More information about the Vm-dev mailing list