I’m replying to this on a new thread so as not to take the LLVMContext: Threads and Ownership discussion too far off topic.
If you did want to fit your use case in to ORC’s model I think the solution would be to clone the module before adding it to the compile layer and (if desired) save a copy of the compiled object and pass a non-owning memory buffer to the linking layer.
That said, if you are not using lazy compilation, remote compilation, or concurrent compilation then using ORC would not buy you much.
We also parallelize lots of things, but this could also work using Orc given that we only use the ObjectLinkingLayer.
In case it is of interest for your tool, here’s the short overview of ORC’s new concurrency support: You can now set up a compiler dispatch function for the JIT that will be called whenever something needs to be compiled, allowing the compilation task to be run on a new thread. Compilation is still triggered on symbol lookup as before, and the compile task is still opaque to the JIT so that clients can supply their own. To deal with the challenges that arise from this (e.g. what if two threads look up the same symbol at the same time? Or two threads look up mutually recursive symbols at the same time?) the new symbol table design guarantees the following invariants for basic lookups: (1) Each symbol’s compiler will be executed at most once, regardless of the number of concurrent lookups made on it, and (2) either the lookup will return an error, or if it succeeds then all pointers returned will be valid (for reading/writing/calling, depending on the nature of the symbol) regardless of how the compilation work was dispatched. This means that you can have lookup calls coming in on multiple threads for interdependent symbols, with compilers dispatched to multiple threads to maximize performance, and everything will Just Work.
If that sounds useful, there will be more documentation coming out in the next few weeks, and I will be giving a talk on the new design at the developer’s meeting.