<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-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span style="font-size:12.800000190734863px">Unless JITed objects are actually written out as proper shared objects I<br></span><span style="font-size:12.800000190734863px">don't see how profilers would understand this?</span></blockquote><div><br></div><div>Yes - The objects would need to be written out. The key point is to try to keep the semantics and formats as close as possible to the statically compiled equivalent.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span style="font-size:12.800000190734863px">There might also be </span><span style="font-size:12.800000190734863px">functions getting mapped to points where another function might have<br></span><span style="font-size:12.800000190734863px">been mapped to previously.</span></blockquote><div><br></div><div>This will depend on the nature of the specific JIT being constructed. For JITs that do re-compilation of functions (rather than just deferring the initial compilation until first call) we will need a mechanism to communicate what has happened to the tools.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span style="font-size:12.800000190734863px">   I suspect this'll continue to need </span><span style="font-size:12.800000190734863px">something like the JITEventListener thing.</span></blockquote><div><span style="font-size:12.800000190734863px"><br></span></div><div><span style="font-size:12.800000190734863px">When I say that we don't want a JITEventListener I mean that we don't want the JITEventListener interface itself (or any fixed set of callbacks). There's no dispute that we need general visibility into the JIT though. Decomposing the JIT into components is meant to improve that.</span></div><div><span style="font-size:12.800000190734863px"><br></span></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span style="font-size:12.800000190734863px"> </span>I'm quite concerned about the API stability around all of this. Postgres<br>releases yearly, and supports 5 years of release branches (so there's 5<br>release branches most of the time).  Having to constantly adapt to<br>changing LLVM APIs in each of those release branches and the dev branch,<br>is going to make using LLVM pretty painful.  If working on the C API is<br>the best way to address that concern, I'm willing to do some of that.</blockquote><div><span style="font-size:12.800000190734863px"><br></span></div><div><span style="font-size:12.800000190734863px">That's a fair concern. LLVM policy is that we don't guarantee stability in either the C or C++ APIs. However we don't make change for changes sake (especially not in the C APIs), so once we have a decent ORC C API I'd expect the churn to be infrequent and hopefully minimally disruptive.</span></div><div><span style="font-size:12.800000190734863px"><br></span></div><div><span style="font-size:12.800000190734863px">Getting *to* a decent ORC C API is another question. Nobody has invested much effort in that yet. Once someone does I'd expect plenty of churn until a decent, tested design emerges.</span></div><div><br></div><div><span style="font-size:12.800000190734863px">Cheers,</span></div><div><span style="font-size:12.800000190734863px">Lang.</span></div><div><span style="font-size:12.800000190734863px"> </span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 3, 2017 at 3:59 PM, 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>
<span class=""><br>
<br>
On 2017-04-03 15:48:38 -0700, Lang Hames wrote:<br>
> Regarding debugging and profiling specifically: the long-term goal is to<br>
> integrate the JIT with the dynamic loader so that JIT'd functions appear to<br>
> the system the same way they would have if they had been dlopen'd<br>
> libraries. This should allow existing profilers and debuggers to be<br>
> used with JIT'd code.<br>
<br>
</span>I doubt that that'll be sufficient for profilers at least - frequently<br>
profiling results will be analyzed when the program has been shut down.<br>
Unless JITed objects are actually written out as proper shared objects I<br>
don't see how profilers would understand this? There might also be<br>
functions getting mapped to points where another function might have<br>
been mapped to previously.   I suspect this'll continue to need<br>
something like the JITEventListener thing.<br>
<span class=""><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>
> The C-bindings haven't received much interest yet, so they're only<br>
> being improved slowly. Adding some callbacks should be easy though.<br>
<br>
</span>Cool.<br>
<span class=""><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>
> There's interest, and I'd love to have some help with it. :)<br>
<br>
</span>Ok.<br>
<br>
<br>
I'm quite concerned about the API stability around all of this. Postgres<br>
releases yearly, and supports 5 years of release branches (so there's 5<br>
release branches most of the time).  Having to constantly adapt to<br>
changing LLVM APIs in each of those release branches and the dev branch,<br>
is going to make using LLVM pretty painful.  If working on the C API is<br>
the best way to address that concern, I'm willing to do some of that.<br>
<span class=""><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>
> I think it would be easy enough to hook up the existing event listener<br>
> interface to RTDyldObjectLayer, it's just that nobody has done it yet.<br>
<br>
</span>I'll take a stab then.<br>
<span class="HOEnZb"><font color="#888888"><br>
- Andres<br>
</font></span></blockquote></div><br></div>