[llvm-dev] Memory usage with MCJit

[Lang Hames via llvm-dev]

Hi Koffie,

I'd highly recommend switching to ORC from MCJIT. It is much more flexible
when it comes to memory-management.

1. I took the approach of 1 execution engine with multiple modules (I'm not
> removing modules once they have been added). During profiling, I noticed
> that the memory usage is high with a lot of code. How can I reduce the
> memory usage? Is one execution engine per module preferred? I would imagine
> that this would take up more memory.


Whether or not you need multiple ExecutionEngines depends on your use case,
but for non-trivial use-cases yes: One ExecutionEngine per Module seems to
be required.

2. When I add a module and jit it, can I invoke a remove module and still
> be able to execute the compiled function?


You can remove the module using ExecutionEngine::removeModule(M), but be
aware that this will clear the global mappings associated with the Module,
so any interfaces that use IR will no longer function.

3. Is it better to have one runtime mem manager that will be associated
> with multiple execution engines (one engine per module)? Using this
> approach I could throw away the execution engines once they have jitted the
> code. I probably need to take ownership of the jitted code somehow. Are
> there any examples available on how this could be achieved?


The MemoryManager owns the JIT'd code. As long as it is alive the code will
hang around. You will need to keep the symbol mappings if you need them.


If you switch to ORC this tends to be easier: You have one stack and can
add as many modules to it as you like. The type of Module pointer that you
add determines the ownership semantics: Pass a raw pointer and the JIT does
not take ownership. Pass a std::unique_ptr<Module> and the JIT does own the
IR. Pass a shared_ptr<Module> and it's shared. The JIT will release the IR
as soon as it is able to.

ORC also frees the relocatable objects as soon as possible (which MCJIT
does not do), so it's likely to have better memory performance over all.

- Lang.


On Mon, Jul 25, 2016 at 8:07 AM, David Blaikie <dblaikie at gmail.com> wrote:

> +Lang for JIT things.
>
> On Sun, Jul 24, 2016 at 8:50 AM koffie drinker via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Hi all,
>>
>> I'm building a runtime that  can jit and execute code. I've followed the
>> kaleidoscope tutorial and had a couple of questions. Basically I have a
>> pre-compiler that compiles the code to cache objects. These cached objects
>> are then persisted  and used to reduce Jit compile time.
>>
>> 1. I took the approach of 1 execution engine with multiple modules (I'm
>> not removing modules once they have been added). During profiling, I
>> noticed that the memory usage is high with a lot of code. How can I reduce
>> the memory usage? Is one execution engine per module preferred? I would
>> imagine that this would take up more memory.
>>
>> 2. When I add a module and jit it, can I invoke a remove module and still
>> be able to execute the compiled function?
>>
>> 3. Is it better to have one runtime mem manager that will be associated
>> with multiple execution engines (one engine per module)? Using this
>> approach I could throw away the execution engines once they have jitted the
>> code. I probably need to take ownership of the jitted code somehow. Are
>> there any examples available on how this could be achieved?
>>
>> cheers,
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160729/1ea4271a/attachment.html>