<div dir="rtl"><div dir="ltr">We have discussed most of these issues, here is a summary and some more issues I thought of -</div><div dir="ltr"><br></div><div dir="ltr">1) Support dynamic linking of <b>C++</b> modules. I have tried it and seems to work - but not reliably. I may have made some programming error, or maybe C++ linking requires more than what the dynamic linker is doing now (vtables related?).</div>
<div dir="ltr"><br></div><div dir="ltr">2) Support function unloading, if possible. If not, a mockup: support function hiding so that a function can be hidden and overridden. </div><div dir="ltr"><br></div><div dir="ltr">
3) Relink function callers to call the new address. Alternatively modify the old function to be a forwarder to the new function, maybe this is simpler. A combined smart "function replacer" function.</div><div dir="ltr">
<br></div><div dir="ltr">
4) Support module unloading, including EH, debug information and fixing the dynamic linker data structures.</div><div dir="ltr"><br></div><div dir="ltr">5) Errors should return error codes instead of aborting.</div>
<div dir="ltr"><br></div><div dir="ltr">6) Have everything scale to 1000s of modules - maybe more. This requires correct datatypes and minimum memory usage, as far as possible.</div><div dir="ltr"><br></div><div dir="ltr">
7) Simplify and minimize the API. Eliminate all JIT and interpreter legacy functions. Eliminate finalize* functions, they should happen automatically. Backward compatibility with JIT is not important as the big issue when transiting from JIT to MCJIT is not the interface but dealing with whole modules instead of functions and no lazy function creation. This requires program redesign.</div>
<div dir="ltr"><br></div><div dir="ltr">8) Several MCJIT function are just forwarders to the dynamic linker, maybe it should be directly exposed in the MCJIT interface.<br></div><div dir="ltr"><br></div><div dir="ltr">9) Move as much out of the API as possible, runFunctions and maybe replaceFunction should be helpers.</div>
<div dir="ltr"><br></div><div dir="ltr">10) Construct MCJIT w/o module. Otherwise special case logic is required between the first and later modules.</div><div dir="ltr"><br></div><div dir="ltr">11) Maybe constructors and destructors should be called automatically before function run and on module exit? </div>
<div dir="ltr"><br></div><div dir="ltr">12) In other words, MCJIT + dynamic linker should ideally handle all the details regular linker does, transparent to the programmer.</div><div dir="ltr"><br></div><div dir="ltr">Yaron</div>
<div dir="ltr"><br></div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote"><div dir="ltr">2013/10/18 Kaylor, Andrew <span dir="ltr"><<a href="mailto:andrew.kaylor@intel.com" target="_blank">andrew.kaylor@intel.com</a>></span></div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Yes, we’ve been planning to separate the execution engines for a while now, and we’ve made some small steps (such as breaking out the RTDyldMemoryManager interface)
in preparation for doing so. There are some serious entanglements, not least of which there are MCJIT clients (LLDB, for instance) which are using memory managers derived from the JITMemoryManager. Eventually (and soon) we’re going to just have to bite the
bullet and go through whatever pain is necessary to make the split.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">There’s going to be a BoF session at the upcoming LLVM Developer Meeting to talk about MCJIT and JIT. One of my goals for that session is to get input from
people who are using these engines to form a plan for ultimate separation and (if the outcry isn’t too great) deprecation of the old engine. Obviously we’ll continue the discussion on the mailing list for people who can’t be at the Dev Meeting, but I was
thinking having a lot of people in one room to talk about it will be a good starting point to get some momentum.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">You’ve been providing a lot of good input and contributions to MCJIT recently. If you aren’t going to be at the Dev Meeting, please consider giving some thought
to what long term visions you might have for MCJIT and send me something so that your voice can be represented in the discussion.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Thanks,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Andy<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Yaron Keren [mailto:<a href="mailto:yaron.keren@gmail.com" target="_blank">yaron.keren@gmail.com</a>]
<br>
<b>Sent:</b> Friday, October 18, 2013 3:10 AM<br>
<b>To:</b> <<a href="mailto:llvmdev@cs.uiuc.edu" target="_blank">llvmdev@cs.uiuc.edu</a>>; Kaylor, Andrew<br>
<b>Subject:</b> EE, JIT, MCJIT class structure<u></u><u></u></span></p><div><div class="h5">
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">The functionality of MCJIT vs JIT had diverged.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Not only they have different operating models (lazy function vs. multi-module), the API is almost completely different. There is a set of functions just for JIT, another set of functions just for MCJIT, with comments saying which ones
work for JIT and which ones work for MCJIT.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">It would make sense for the EE to have only the shared functionality and the inheriting classes JIT and MCJIT exposing their specialized functionality.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">This requires exposing JIT and MCJIT headers, including a JITcreater and a MCJITcreator or suitable constructors.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Yaron<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
</div></div></div>
</div>
</blockquote></div><br></div>