[llvm-dev] LLVMContext: Threads and Ownership.

[Alex Denisov via llvm-dev]

Hi Lang,

> We would like to deallocate contexts


I did not look at the Orc APIs as of LLVM-6+, but I'm curious where this requirement comes from?
Does Orc takes ownership of the modules that are being JIT'ed? I.e., it is the same 'ownership model' as MCJIT has, am I right?

I think the JIT users should take care of memory allocation/deallocation. Also, I believe that you have strong reasons to implement things this way :)
Could you please tell us more about the topic?

> On 16. Sep 2018, at 01:14, Lang Hames via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> Hi All,
> 
> ORC's new concurrent compilation model generates some interesting lifetime and thread safety questions around LLVMContext: We need multiple LLVMContexts (one per module in the simplest case, but at least one per thread), and the lifetime of each context depends on the execution path of the JIT'd code. We would like to deallocate contexts once all modules associated with them have been compiled, but there is no safe or easy way to check that condition at the moment as LLVMContext does not expose how many modules are associated with it.
> 
> One way to fix this would be to add a mutex to LLVMContext, and expose this and the module count. Then in the IR-compiling layer of the JIT we could have something like:
> 
> // Compile finished, time to deallocate the module.
> // Explicit deletes used for clarity, we would use unique_ptrs in practice.
> auto &Ctx = Mod->getContext();
> delete Mod;
> std::lock_guard<std::mutex> Lock(Ctx->getMutex());
> if (Ctx.getNumModules())
>   delete Ctx;
> 
> Another option would be to invert the ownership model and say that each Module shares ownership of its LLVMContext. That way LLVMContexts would be automatically deallocated when the last module using them is destructed (providing no other shared_ptrs to the context are held elsewhere).
> 
> There are other possible approaches (e.g. side tables for the mutex and module count) but before I spent too much time on it I wanted to see whether anyone else has encountered these issues or has opinions on solutions.
> 
> Cheers,
> Lang.
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180916/9a42d654/attachment.sig>