[llvm-dev] OrcV1 removal

[Lang Hames via llvm-dev]

Hi Andres,

I was wondering about it because the function comments didn't mention it
> (or at least I didn't see it), and not "implicitly" prevent via type
> system. I don't really have a use case.


I tried to think of a nice way to do this with the type system but
everything I tried came out awkward.

One use case I *can* think of for cross-dylib tracking is the current
system for CompileOnDemandLayer: It creates a ".impl" JITDylib for each
JITDylib you add code to, installs the code in the ".impl" JITDylib and
builds stubs in the original JITDylib, treating it as a facade. I haven't
implemented removal properly for this yet, but my plan was to create new
ResourceTrackers as needed and treat them as resources themselves in
CompileOnDemandLayer: If you add a module with tracker T then
CompileOnDemandLayer would create a tracker T' and record the association
key(T) -> T'. Then on removal of T we would extract and trigger removal of
T'. If ResourceTrackers worked across JITDylib boundaries we could avoid
this, but it's not particularly complicated anyway.

I'm going to leave the current solution in place for now, but if anyone
does come up with a compelling use-case for cross-dylib tracking please let
me know. :)

-- Lang.



On Wed, Sep 16, 2020 at 3:13 PM Andres Freund <andres at anarazel.de> wrote:

> Hi,
>
> On 2020-09-16 14:53:44 -0700, Lang Hames wrote:
> > > I assume it is not legal to use the same resource tracker with two
> > > different JITDylib's?
> >
> >
> > That's correct -- ResourceTrackers are bound to the JITDylib they're
> > created from. They should assert if you use them with the wrong JITDylib,
> > though I'm not sure how good the coverage on those asserts are yet.
> >
> > I think this system could be generalized to enable cross-dylib tracking
> at
> > the cost of a few dozen extra bytes per tracker. Do you have a use-case
> for
> > this?
>
> I was wondering about it because the function comments didn't mention it
> (or at least I didn't see it), and not "implicitly" prevent via type
> system. I don't really have a use case.
>
> Greetings,
>
> Andres Freund
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200916/9db33090/attachment.html>