<div dir="ltr">Hi Koffie,<div><br></div><div>I'd highly recommend switching to ORC from MCJIT. It is much more flexible when it comes to memory-management.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:12.800000190734863px">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.</span></blockquote><div><span style="font-size:12.800000190734863px"><br></span></div><div><span style="font-size:12.800000190734863px">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.</span></div><div><span style="font-size:12.800000190734863px"><br></span></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:12.800000190734863px">2. When I add a module and jit it, can I invoke a remove module and still be able to execute the compiled function?</span></blockquote><div><span style="font-size:12.800000190734863px"><br></span></div><div><span style="font-size:12.800000190734863px">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.</span></div><div><span style="font-size:12.800000190734863px"><br></span></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:12.800000190734863px">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?</span></blockquote><div><br></div><div>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.</div><div><br></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>- Lang.</div><div><span style="font-size:12.800000190734863px"><br></span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 25, 2016 at 8:07 AM, David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">+Lang for JIT things.<br><br><div class="gmail_quote"><div><div class="h5"><div dir="ltr">On Sun, Jul 24, 2016 at 8:50 AM koffie drinker via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr">Hi all,<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>2. When I add a module and jit it, can I invoke a remove module and still be able to execute the compiled function?</div><div><br></div><div>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?</div><div><br></div><div>cheers,</div><div><br></div></div></div></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div>
</blockquote></div><br></div>