<div dir="ltr"><div dir="ltr"><div dir="ltr">Hi Andres,<div><br></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">Yes, I do prefer less churn. It's not a deal breaker, but I try to keep<br>PG compiling against trunk LLVM, and there's multiple stable branches -<br>so it's somewhat noisy to do that repeatedly (including syncing up that<br>all the LLVM trunk test machines update at the same time).</blockquote></div><div><br></div><div>Ok -- I'll make getting the new lookup API working a priority then.</div><div><br></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">I see a memory leak with OrcV2 that I didn't see with V1. I'm not yet<br>sure where exactly they're coming from. Possible that I'm just missing a<br>step somewhere. Or something around the removable code support doesn't<br>yet fully work.</blockquote></div><div><br></div><div>I just checked and I've migrated ObjectLinkingLayer to support ResourceTracker, but not RTDyldObjectLinkingLayer yet. If you're testing on Linux there's a good chance that's the source of your leak. I'll get that updated tonight.</div><div><br></div><div>-- Lang.</div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 30, 2020 at 6:26 PM Andres Freund <<a href="mailto:andres@anarazel.de">andres@anarazel.de</a>> wrote:<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">Hi,<br>
<br>
On 2020-09-30 17:52:46 -0700, Lang Hames wrote:<br>
> I've just realised that we're going to need a change to the definition<br>
> generator API in the long term: Right now it is called under the session<br>
> lock, but we want to shift to calling it outside the lock and passing a<br>
> lookup-continuation. This would allow definition discovery to take an<br>
> arbitrarily long time without blocking forward progress on other JIT work.<br>
<br>
Sounds useful.<br>
<br>
<br>
> I'm guessing your objective for now is to minimize churn, right? If that's<br>
> the case I'll focus on moving to the continuation passing API on the<br>
> orcv1-removal branch before I update the C API.<br>
<br>
Yes, I do prefer less churn. It's not a deal breaker, but I try to keep<br>
PG compiling against trunk LLVM, and there's multiple stable branches -<br>
so it's somewhat noisy to do that repeatedly (including syncing up that<br>
all the LLVM trunk test machines update at the same time).<br>
<br>
<br>
I see a memory leak with OrcV2 that I didn't see with V1. I'm not yet<br>
sure where exactly they're coming from. Possible that I'm just missing a<br>
step somewhere. Or something around the removable code support doesn't<br>
yet fully work.<br>
<br>
Greetings,<br>
<br>
Andres Freund<br>
</blockquote></div>