[Vm-dev] callbacks and Cog

[Eliot Miranda]

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 at gmail.com> wrote:

>
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20090506/8b672baa/attachment-0001.htm