[LLVMdev] Memory clean for applications using LLVM for JIT compilation

[Frank Henigman]

> On 14 Jan 2013, at 15:48, Reid Kleckner <rnk at google.com> wrote:
> >
> > Or maybe would it be possible to have a custom allocator for memory space for the native code that we could provide? With this last option we would be responsible for the clean up ourselves and just provide memory space to LLVM where it can store the results.
> >
> > Yes, you should be able to inherit from llvm::JITMemoryManager and do something like this.

> I've been trying to work with this solution, but it does pose a problem. The problem is that we use an ExecutionEngine and set a memory manager with setJITMemoryManager on EngineBuilder. The problem is that this means when the ExecutionEngine is deallocated, it end up deallocating the memory manager.

> I can understand doing this when the code sets up it's own memory manager, but with an external memory manager, I'd expect LLVM not to deallocate that object for me. Is there a way to prevent this from happening? I can't keep the ExecutionEngine around here either, since EngineBuilder needs a Module, which in it's turn needs an LLVMContext, which I'm trying to create for each new request.

> Does anyone have additional ideas for how to handle this? Or whether there is another approach that could work here?

I derived a class from JITMemoryManager which delegates everything to
an instance made with CreateDefaultMemManager().  ExecutionEngine
destroys the wrapper, but I keep the inner instance which did the
actual work.  Works, but seems a bit ugly.  Did you find any other
solutions?