<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><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 class=""><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 class=""><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="HOEnZb"><div class="h5"><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_3321048080087228631m_-2196607864701703492gmail-Apple-tab-span" style="white-space:pre-wrap"> </span>LLVMLinkInOrcMCJITReplacement(<wbr>);</div><div><span class="m_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_3321048080087228631HOEnZb"><div class="m_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_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>