[llvm-dev] [ORC] Removing / replacing JITDylibs

Lang Hames via llvm-dev llvm-dev at lists.llvm.org
Thu Aug 22 14:23:48 PDT 2019


Hi Kavon,

Unfortunately we don't have a good way to do this at the moment, short of
maintaining multiple execution sessions (analogous to the way you
maintained multiple ExecutionEngines).

I am working on initializer/destructor support that will allow us to
perform the equivalent of dlopen/dlclose on JITDylibs. Once that support is
available I think it would be a good fit for your use case. Unfortunately I
think it is still a few months away.

Cheers,
Lang.

On Mon, Aug 19, 2019 at 3:38 PM Kavon Farvardin via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Hi,
>
> I'm working on a runtime autotuner that utilizes ORCv2 JIT (I'm closely
> tracking tip-of-tree), so linking new object files and patching in the new
> function(s) will happen frequently.
>
> One of the concerns my runtime system has is the ability to do one of the
> following: (1) replacement of the contents of a JITDylib with a new object
> file [to provide semi-space GC-style reclaiming], (2) the outright removal
> of a JITDylib.
>
> Right now, I have one ExecutionSession instance for my linker and am
> creating a new JITDylib for each object file that I'd like to link in.
> There doesn't appear to be a
> corresponding ExecutionSession::removeJITDylib(..) method, so I'm
> wondering: how do I reclaim the memory for code that I've linked in
> previously but no longer need?
>
> When using MCJIT, I would reclaim this memory by destroying the
> ExecutionEngine that was created for each "JITDylib". Should I do the same
> with ExecutionSessions?
>
> For reference, here's the short bit of code I'm playing with for linking
> with ORC:
>
> https://github.com/halo-project/llvm/blob/master/compiler-rt/lib/halomon/DynamicLinker.h#L55
>
> Thanks,
> Kavon
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190822/e57a5981/attachment.html>


More information about the llvm-dev mailing list