Igor,<div><br></div><div> 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).<br>
<br><div class="gmail_quote">On Wed, May 6, 2009 at 10:20 AM, Igor Stasenko <span dir="ltr"><<a href="mailto:siguctua@gmail.com">siguctua@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
2009/5/6 Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>>:<br>
<div class="im">><br>
> Hi All,<br>
> 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.<br>
> 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?<br>
<br>
</div>I don't know how this can be applied to Cog, but you could use a<br>
simple indirection, when returning from callback - instead of pushing<br>
a direct return address (by using call CPU instruction), use a<br>
continuation-style call, like:<br>
<br>
1. pushRemappableOop(mycallInfo).<br>
2. jump to procedure which is statically compiled (in C) , which<br>
a) reenters the interpreter, and<br>
b) upon return does popRemappableOop, read the return address from<br>
there and then jumps to that address.<br>
<br>
of course, push/pop remappable oop can be replaced by something else,<br>
which could help you to deal with relocation.<br>
> best<br>
> Eliot<br>
><br>
<font color="#888888"><br>
<br>
<br>
--<br>
Best regards,<br>
Igor Stasenko AKA sig.<br>
</font></blockquote></div><br></div>