<div dir="ltr">Hi Andres,<div><br></div><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 style="font-size:12.800000190734863px">I started out using MCJIT but it looks like that's slowly on the way<br></span><span style="font-size:12.800000190734863px">out.  My current concern is that neither the ORC MCJIT replacement, nor<br></span><span style="font-size:12.800000190734863px">the ORC C bindings appear to provide integration into JIT event<br></span><span style="font-size:12.800000190734863px">listeners.  Which I find a bit surprising - without gdb and/or profiler<br></span><span style="font-size:12.800000190734863px">integration, how is one supposed to actually use a JIT successfully?</span></blockquote><div><span style="font-size:12.800000190734863px"><br></span></div><div><span style="font-size:12.800000190734863px">ORC is a set of components to build a JIT, rather than a black-box JIT like LLVM. The aim is to give clients more visibility into the workings of the JIT by hooking into compositions points (e.g. using a TransformLayer between other JIT layers) or by writing custom components, rather than being limited to the fixed callbacks provided by JITEventListener. Exactly how this will fit into the C API has not been explored yet.</span></div><div><span style="font-size:12.800000190734863px"><br></span></div><div><span style="font-size:12.800000190734863px">Regarding debugging and profiling specifically: the long-term goal is to integrate the JIT with the dynamic loader so that JIT'd functions appear to the system the same way they would have if they had been dlopen'd libraries. This should allow existing profilers and debuggers to be used with JIT'd code.</span></div><div><span style="font-size:12.800000190734863px"><br></span></div><div><span style="font-size:12.800000190734863px"><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">It'd not be too bad if I had to use a small bit of, optional, code to<br>register a JIT event listener, but otherwise use the C API (that's what<br>I currently do for perf support in MCJIT), but it doesn't look like<br>that's an option with the ORC C bindings (RTDyldObjectLinkingLayer's<br>integration is a class template parameter defaulting to<br>DoNothingOnNotifyLoaded), and it's not used by OrcCBindingsStack.</blockquote></span></div><div><span style="font-size:12.800000190734863px"><br></span></div><div><span style="font-size:12.800000190734863px">The C-bindings haven't received much interest yet, so they're only being improved slowly. Adding some callbacks should be easy though.</span></div><div><span style="font-size:12.800000190734863px"><br></span></div><div><span style="font-size:12.800000190734863px"><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">Is there interest in addressing these issues, or is the position more<br>generally that the C bindings aren't going to be useful enough?  I'm<br>willing to work on that, but only if there's actual interest in<br>integrating things...</blockquote><div><br></div><div>There's interest, and I'd love to have some help with it. :)</div><div><br></div><div><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">I'm also a bit confused about RTDyldObjectLinkingLayer's notify<br>integration.  NotifyLoadedFtor is a class template parameter, but<br>NotifyFinalizedFtor is just a std::function defaulting to empty?  Is<br>that just for historical raisins, or is there a deeper reason?</blockquote></div><div><br></div><div>Historical raisins. I'm working on a substantial ORC refactor that should be landing soon and this will make NotifyLoaded a std::function.</div><div><br></div><div><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">To be able to use existing JITEventListeners - it'd surely be a shame to<br>have to rewrite them anew - in custom stacks it also appears that<br>there's no easy way to call JITEventListener->NotifyFreeingObject() -<br>the to-be-freed objects aren't readily available in<br>RTDyldObjectLinkingLayer.</blockquote></div><div><br></div><div>I think it would be easy enough to hook up the existing event listener interface to RTDyldObjectLayer, it's just that nobody has done it yet. </div><div><br></div><div>- Lang.</div><div><br></div></span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 8, 2017 at 11:47 AM, Andres Freund <span dir="ltr"><<a href="mailto:andres@anarazel.de" target="_blank">andres@anarazel.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
I am working on using LLVM to compile parts of longrunning PostgreSQL<br>
queries into native code for faster code execution.  As postgres is,<br>
nearly, entirely written in C and has long-lived (5 years) supported<br>
branches (making the higher API stability important), I'm currently<br>
using the C API.<br>
<br>
I started out using MCJIT but it looks like that's slowly on the way<br>
out.  My current concern is that neither the ORC MCJIT replacement, nor<br>
the ORC C bindings appear to provide integration into JIT event<br>
listeners.  Which I find a bit surprising - without gdb and/or profiler<br>
integration, how is one supposed to actually use a JIT successfully?<br>
<br>
It'd not be too bad if I had to use a small bit of, optional, code to<br>
register a JIT event listener, but otherwise use the C API (that's what<br>
I currently do for perf support in MCJIT), but it doesn't look like<br>
that's an option with the ORC C bindings (RTDyldObjectLinkingLayer's<br>
integration is a class template parameter defaulting to<br>
DoNothingOnNotifyLoaded), and it's not used by OrcCBindingsStack.<br>
<br>
In addition, it doesn't currently look there's C API to force the mcjit<br>
replacement being used?<br>
<br>
Is there interest in addressing these issues, or is the position more<br>
generally that the C bindings aren't going to be useful enough?  I'm<br>
willing to work on that, but only if there's actual interest in<br>
integrating things...<br>
<br>
<br>
I'm also a bit confused about RTDyldObjectLinkingLayer's notify<br>
integration.  NotifyLoadedFtor is a class template parameter, but<br>
NotifyFinalizedFtor is just a std::function defaulting to empty?  Is<br>
that just for historical raisins, or is there a deeper reason?<br>
<br>
<br>
To be able to use existing JITEventListeners - it'd surely be a shame to<br>
have to rewrite them anew - in custom stacks it also appears that<br>
there's no easy way to call JITEventListener-><wbr>NotifyFreeingObject() -<br>
the to-be-freed objects aren't readily available in<br>
RTDyldObjectLinkingLayer.<br>
<br>
Greetings,<br>
<br>
Andres Freund<br>
</blockquote></div><br></div>