Hi Andres,
Yes, I do prefer less churn. It's not a deal breaker, but I try to
keep> PG compiling against trunk LLVM, and there's multiple stable branches -
> so it's somewhat noisy to do that repeatedly (including syncing up that
> all the LLVM trunk test machines update at the same time).
Ok -- I'll make getting the new lookup API working a priority then.
I see a memory leak with OrcV2 that I didn't see with V1. I'm not
yet> sure where exactly they're coming from. Possible that I'm just
missing a
> step somewhere. Or something around the removable code support doesn't
> yet fully work.
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.
-- Lang.
On Wed, Sep 30, 2020 at 6:26 PM Andres Freund <andres at anarazel.de>
wrote:
> Hi,
>
> On 2020-09-30 17:52:46 -0700, Lang Hames wrote:
> > I've just realised that we're going to need a change to the
definition
> > generator API in the long term: Right now it is called under the
session
> > lock, but we want to shift to calling it outside the lock and passing
a
> > lookup-continuation. This would allow definition discovery to take an
> > arbitrarily long time without blocking forward progress on other JIT
> work.
>
> Sounds useful.
>
>
> > I'm guessing your objective for now is to minimize churn, right?
If
> that's
> > the case I'll focus on moving to the continuation passing API on
the
> > orcv1-removal branch before I update the C API.
>
> Yes, I do prefer less churn. It's not a deal breaker, but I try to keep
> PG compiling against trunk LLVM, and there's multiple stable branches -
> so it's somewhat noisy to do that repeatedly (including syncing up that
> all the LLVM trunk test machines update at the same time).
>
>
> I see a memory leak with OrcV2 that I didn't see with V1. I'm not
yet
> sure where exactly they're coming from. Possible that I'm just
missing a
> step somewhere. Or something around the removable code support doesn't
> yet fully work.
>
> Greetings,
>
> Andres Freund
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200930/cf48b209/attachment.html>