[llvm-dev] OrcV1 removal

[Lang Hames via llvm-dev]

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>