Frank Henigman
2013-Mar-08 04:48 UTC
[LLVMdev] Memory clean for applications using LLVM for JIT compilation
> 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?
Dirkjan Bussink
2013-Mar-16 15:35 UTC
[LLVMdev] Memory clean for applications using LLVM for JIT compilation
On Mar 7, 2013, at 20:48 , Frank Henigman <fjhenigman at google.com> wrote:> 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?I ended up implementing the exact same thing, it feels dirty but it has worked great for us so far. -- Dirkjan
Frank Henigman
2013-Mar-17 21:17 UTC
[LLVMdev] Memory clean for applications using LLVM for JIT compilation
Thanks for the reply, nice to have some validation. I thought of another approach which might be preferable: generate relocatable code, use a JITEventListener to grab each function and copy it to my own memory, let all the LLVM stuff die normally then use my copy of the code. However when I call setRelocationModel(Reloc::PIC_) on the engine builder I get code that seg faults. The assembly looks plausible at a glance, but I'm not really up to speed on x86 assembly. Is PIC supposed to work with JIT on X86-32? On Sat, Mar 16, 2013 at 11:35 AM, Dirkjan Bussink <d.bussink at gmail.com> wrote:> > On Mar 7, 2013, at 20:48 , Frank Henigman <fjhenigman at google.com> wrote: > >> 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? > > I ended up implementing the exact same thing, it feels dirty but it has worked great for us so far. > > -- > Dirkjan
Apparently Analagous Threads
- [LLVMdev] Memory clean for applications using LLVM for JIT compilation
- [LLVMdev] Memory clean for applications using LLVM for JIT compilation
- [LLVMdev] Memory clean for applications using LLVM for JIT compilation
- [LLVMdev] Memory clean for applications using LLVM for JIT compilation
- [LLVMdev] Memory clean for applications using LLVM for JIT compilation