<div dir="ltr">Hi Lang,<div><br></div><div>I actually meant, create execution engine, add module, jit, delete module/execution engine and only keep the jitted memory parts</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 17, 2016 at 8:10 PM, Lang Hames <span dir="ltr"><<a href="mailto:lhames@gmail.com" target="_blank">lhames@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">Hi Koffie,<div><br></div><div>What you've described sounds like the KaleidoscopeJIT class from <a href="http://llvm.org/docs/tutorial/BuildingAJIT1.html" target="_blank">http://llvm.org/docs/<wbr>tutorial/BuildingAJIT1.html</a> : Modules that are added are compiled to executable code and the module immediately deleted. The executable code persists until the JIT instance is destroyed, or you call "removeModule" (passing the handle returned from addModule).</div><div><br></div><div>Cheers,</div><div>Lang.</div><div><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 17, 2016 at 6:00 AM, koffie drinker <span dir="ltr"><<a href="mailto:gekkekoe@gmail.com" target="_blank">gekkekoe@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"><div>Hi Lang,<br></div><div><br></div><div>I'm starting to migrate the MCJIT to ORC. </div><div>The ideal scenario for a jit would be to generate the code and release module related objects.</div><div><br></div><div>I had this in mind:</div><div>- Add module to jit</div><div>- Generate code</div><div>- Remove module</div><div>- Retain memory section that was used to store the generated code. </div><div><br></div><div>Using this scenario, memory usage will be kept to a minimum. (I'm seeing quite some mem usage with MCJIT, it allocates a lot of memory but only uses small portion of it).</div><div>Do you have any pointers on how to get this starting ? I'm willing to share the results once it's finished. I might be useful to others as well.<br></div><div><div class="m_-5536252081195317725h5"><div><br></div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 17, 2016 at 12:54 AM, Lang Hames <span dir="ltr"><<a href="mailto:lhames@gmail.com" target="_blank">lhames@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">Hi Kevin, Koffie,<span><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">We will start migrating to ORC for next release, but for now, this release invoke delete after remove right?</span></blockquote><div><span style="font-size:12.800000190734863px"><br></span></div></span><div><span style="font-size:12.800000190734863px">MCJIT's removeModule method does not delete the module. You'll need to do that manually. OrcMCJITReplacement is a bug-for-bug compatible implementation of MCJIT using ORC components, so it does not free the memory either.</span></div><span><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">Does this mean MCJIT is dead/deprecated and projects using it should start<br></span><span style="font-size:12.800000190734863px">migrating away now? If so, what's the time frame?</span></blockquote><div><br></div></span><div>The short answer is yes: I expect MCJIT to be deprecated soon and eventually killed off. I'll be sending an email with details and a discussion of the timeline to the dev-list in the next few days. That will contain suggestions on how to transition to the new APIs (which I expect to be relatively painless for most people). I can CC you on it if that helps?</div><div><br></div><div>Cheers,</div><div>Lang.</div><div><span style="font-size:12.800000190734863px"></span><br></div></div><div class="m_-5536252081195317725m_-553565970500438946HOEnZb"><div class="m_-5536252081195317725m_-553565970500438946h5"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 11, 2016 at 12:00 AM, koffie drinker via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</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">There's a orc mcjit drop in replacement in the source tree.<div>Am I correct to assume that Orc is used (and emulating mcjit behaviour) when replacing</div><div><div><span class="m_-5536252081195317725m_-553565970500438946m_3321048080087228631m_-2196607864701703492gmail-Apple-tab-span" style="white-space:pre-wrap"> </span>LLVMLinkInOrcMCJITReplacement(<wbr>);</div><div><span class="m_-5536252081195317725m_-553565970500438946m_3321048080087228631m_-2196607864701703492gmail-Apple-tab-span" style="white-space:pre-wrap"> </span>//LLVMLinkInMCJIT();</div></div><div>and linking with libOrcJit ?</div><div>Does this replacement handle memory better than original mcjit ?</div><div><br></div></div><div class="m_-5536252081195317725m_-553565970500438946m_3321048080087228631HOEnZb"><div class="m_-5536252081195317725m_-553565970500438946m_3321048080087228631h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 7, 2016 at 8:39 PM, Kevin P. Neal via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Fri, Nov 04, 2016 at 04:20:32PM -0700, Lang Hames via llvm-dev wrote:<br>
> Hi Koffie,<br>
> Kaleidoscope is no longer using MCJIT - it has been moved over to the<br>
> ORC-based KaleidoscopeJIT class (see<br>
> llvm/examples/Kaleidoscope/inc<wbr>lude/KaleidoscopeJIT.h). The removeModule<br>
> method there does not leak memory.<br>
> I've added documentation in r286026 to describe MCJIT removeModule's<br>
> crazy ownership contract.<br>
> This will be fixed properly when we kill off ExecutionEngine. :)<br>
<br>
</span>Does this mean MCJIT is dead/deprecated and projects using it should start<br>
migrating away now? If so, what's the time frame?<br>
<span class="m_-5536252081195317725m_-553565970500438946m_3321048080087228631m_-2196607864701703492HOEnZb"><font color="#888888"><br>
--<br>
Kevin P. Neal <a href="http://www.pobox.com/~kpn/" rel="noreferrer" target="_blank">http://www.pobox.com/~kpn/</a><br>
<br>
"It sounded pretty good, but it's hard to tell how it will work out<br>
in practice." -- Dennis Ritchie, ~1977, "Summary of a DEC 32-bit machine"<br>
______________________________<wbr>_________________<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/<wbr>mailman/listinfo/llvm-dev</a><br>
</font></span></blockquote></div><br></div>
</div></div><br>______________________________<wbr>_________________<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/<wbr>mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div>
</div></div></blockquote></div><br></div></div></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>