llvm dev - Mar 2013 - [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?

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

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