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

Kavon Farvardin via llvm-dev llvm-dev at lists.llvm.org
Fri Aug 23 09:18:44 PDT 2019

Thanks for the reply, Lang! I really appreciate the effort you've been putting
into the JIT infrastructure and that you take the time to answer lots of
questions about it on the mailing list.
> I am working on initializer/destructor support that will allow us to perform
> the equivalent of dlopen/dlclose on JITDylibs.

In my case, the process is already running with one version of the program code,
and another thread is hot-patching functions with dynamically recompiled
versions (I've extended XRay for this). Thus, I actually want to avoid
reinitializing or creating new versions of globals for the Dylib output by ORC
and instead link with the ones in-process.
My plan for achieving this is to externalize all internal globals in the
original bitcode before JIT compilation and hope that the ORC dynamic linker
handles the rest automatically.
On Thu, 2019-08-22 at 14:23 -0700, Lang Hames wrote:
> 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: 
> > 
> > 
> > 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/20190823/0336c40c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190823/0336c40c/attachment-0001.sig>

More information about the llvm-dev mailing list