<div dir="ltr">Hi Sanjoy,<div><br></div><div>> You need the hijack-return-pc approach *in addition* to a call-site<br>> patching approach.  Modifying the return PC lets you guarantee that<br>> nothing will *return* into the old generated code. To guarantee that<br>> nothing will *call* into it either you could use a double indirection<br>> (all calls go through a trampoline) or patchpoints.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">You need to hijack the return addresses if you want to delete the original function body immediately, but what if you just leave the original in-place until you return through it? That is the scheme that Pete and I had been talking about. On the one-hand that means that the old code may live for an arbitrarily long time, on the other hand it saves you from implementing some complicated infrastructure. I suspect that in most JIT use-cases the cost of keeping the duplicate function around will be minimal, but I don't actually have any data to back that up. :)</div><div class="gmail_extra"><br></div><div class="gmail_extra">It's worth noting that, as per its design goals, Orc is agnostic about all this. Either scheme, or both, should be able to be implemented in the new framework. It's just that nobody has implemented it yet.</div><div class="gmail_extra"><br></div><div class="gmail_extra">- Lang.</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 20, 2015 at 4:55 AM, Sanjoy Das <span dir="ltr"><<a href="mailto:sanjoy@playingwithpointers.com" target="_blank">sanjoy@playingwithpointers.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">> That all makes sense. What are your thoughts on the trade-offs of this vs<br>
> the patchpoint approach though? If you can modify previously executable<br>
> memory it seems like the patchpoint approach would have lower overhead,<br>
> unless you have a truly huge number of callsites to update?<br>
<br>
</span>You need the hijack-return-pc approach *in addition* to a call-site<br>
patching approach.  Modifying the return PC lets you guarantee that<br>
nothing will *return* into the old generated code. To guarantee that<br>
nothing will *call* into it either you could use a double indirection<br>
(all calls go through a trampoline) or patchpoints.<br>
<span class=""><font color="#888888"><br>
-- Sanjoy<br>
</font></span></blockquote></div><br></div></div>