<div dir="rtl"><div dir="ltr">Hi Andy,</div><div dir="ltr"><br></div><div dir="ltr">I have been following Julia with interest, as it's a type-optional language designed to be as nice as dynamic languages but run at the speed of compiled C++ programs. They achieve this by deducing as many types at compile time and JITing code for the unknown types at runtime when they are known. That's a smart use of a JIT. In C++ terms it's analog to instantiating templates at runtime.</div>
<div dir="ltr"><br></div><div dir="ltr">Julia has programmer-controllable dynamic dispatching of functions according to the best "match". I guess that is the place where the stub function management happen. All together it's very nice and smart design.<br>
</div><div dir="ltr"><br></div><div dir="ltr">The nice thing about the legacy JIT is that it just works with modified code. All you need is to call freeMachineCodeForFunction and the JIT will automatically re-compile and update the stub. It's very easy to use. </div>
<div dir="ltr"><br></div><div dir="ltr">The JIT stub functions are not real functions but just jumps which the JIT keeps track of and updates as needed. This implementation does not have the problem of different names for the stub and real functions as the stub functions do not exists in the IR. From the programmer perspective it's a technical detail the JIT takes care of.</div>
<div dir="ltr"><br></div><div dir="ltr"></div><div dir="ltr">Stubs in IR or MC are not trivial to implement so it would be nice to continue providing clients this functionality after the JIT is gone. It's not required that to have the functionality in the MCJIT itself. A "FunctionJIT" could provides Function-level services and stub functions to a client, using MCJIT as its engine.</div>
<div dir="ltr"><br></div><div dir="ltr">Regarding module removal, MCJIT or the linker needs to keep maps at least for the object, EH data, debug info so they could be removed (EH data is currently removed when the JIT is destroyed). In addition, the issues you mentioned need to be cared of. Symbols need to be removed from the linker. There are lots of details. <br>
</div><div dir="ltr"><br></div><div dir="ltr"><div>Yaron</div><div><br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote"><div dir="ltr">2013/11/14 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">Hi Yaron,<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">I think a lot of what I said in my reply to Gaël also applies to your situation. In particular, I think that it’s probably best for your code to manager the
function stubs and replacement. I talked last week with a developer who works on the Julia language (which shares a lot of features your situation) and it’s my understanding that the Julia runtime handles function stubs and function replacement in a way that
is similar to what I described even though they are currently using the old JIT engine (not coincidental since my discussions with him helped shape my ideas about how to do this).<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">Module deletion is clearly a bit of a problem currently. This is on my wish list of things for MCJIT to support. One of the biggest barriers to module deletion
is that MCJIT doesn’t track links between generated objects, so if you want to delete an object that is being called from another generated object that would be a problem. Using client-managed stubs for inter-module linking obviously helps with this problem.<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">The other issue is that we aren’t currently telling the memory manager which module any given allocation request is associated with. There are some clues that
a sufficiently motivated memory manager could possibly use to figure it out, but there’s nothing to directly support it.<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">I think the module deletion case is worth discussing further. I’d be happy to hear proposals for changes to support it.<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">Registration of EH frame information as new modules are added should work in MCJIT. If it doesn’t that’s a bug.<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">-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"><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> Wednesday, November 13, 2013 1:56 PM<br>
<b>To:</b> Kaylor, Andrew<br>
<b>Cc:</b> Gaël Thomas; <a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank">llvm-commits@cs.uiuc.edu</a>; LLVM Dev<br>
<b>Subject:</b> Re: (Very) small patch for the jit event listener<u></u><u></u></span></p><div><div class="h5">
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">Hi Andy,<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">We had previous discussions about this, I'd like to state more exactly what features would make MCJIT a replacement for the JIT. <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">After putting significant effort trying to move to MCJIT, I'm currently back with the JIT. This is in a REPL environment where functions are added and removed dynamically and response time is important. The issue is the legacy JIT provides
great flexibility for this use case which is currently missing from MCJIT because of their very different design and goals.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">With JIT, you can modify Function(s) in an already-compiled Module, unload the machine code and the JIT will automatically recompile and relink the function next time it is called. To make MCJIT work like that it would need at least :<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">1) Automatic module splitting into function-modules.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">2) Module delete: from module list, from linker namespace, machine code unload, unregister EH and debuginfo.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">3) Stub functions.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">4) Relinking with stub functions so that new modules are relinked without changing already-finalized modules. This is critical to response time as you may change just one function out of 1000.<u></u><u></u></p>
</div>
<div>
<div>
<p class="MsoNormal">5) Module addition should register EH and debuginfo (this is not done with current JIT but while at it...).<u></u><u></u></p>
</div>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">REPL environments using the LLVM JIT would likely encounter great difficulty moving to the current MCJIT without the above. 1) could be done by the programmer but the a helper function should provide this service. 2)-4) could be done only
in the MCJIT. 5) is a bonus.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Until MCJIT has this kind of flexibility, I hope the JIT would be kept alive.<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>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">2013/11/13 Kaylor, Andrew <<a href="mailto:andrew.kaylor@intel.com" target="_blank">andrew.kaylor@intel.com</a>><u></u><u></u></p>
</div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">Hi Gaël,<br>
<br>
I'm not familiar enough with the details of the old JIT engine and its event interface to comment on whether or not your changes are appropriate, but I'm not sure anyone is so the patch is probably OK as is. I don't see any obvious problems with it.<br>
<br>
However, your description of the changes raises a bigger issue in my mind. I'm not sure if you are aware of this, but we're planning to deprecate the old JIT engine in a future release -- possibly as soon as LLVM 3.5. In order to do so we need to make sure
the MCJIT engine is capable of meeting the needs of current JIT users, and I'm not sure we've got your case fully covered yet.<br>
<br>
Can you tell me a little bit more about the details of how you are using the JIT engine? I'm putting together a document describing various models for MCJIT use and if your model isn't covered by one of the cases I've got now I'd like to add it.<br>
<br>
Also, have you looked at the recently added Stackmap and Patchpoint intrinsics. Without knowing a lot about either your case or those intrinsics, I think that there may be a possible match there. The thing that raised a red flag for me in your message was
that MCJIT doesn't maintain mappings between the generated code and the LLVM classes from which it is produced, so we'll probably need a different way to handle your safepoints.<br>
<br>
(BTW, it's probably appropriate to move further discussion to the LLVMDev list rather than llvm-commits.)<br>
<br>
Thanks,<br>
Andy<br>
<br>
<br>
-----Original Message-----<br>
From: <a href="mailto:llvm-commits-bounces@cs.uiuc.edu" target="_blank">llvm-commits-bounces@cs.uiuc.edu</a> [mailto:<a href="mailto:llvm-commits-bounces@cs.uiuc.edu" target="_blank">llvm-commits-bounces@cs.uiuc.edu</a>] On Behalf Of Gaël Thomas<br>
Sent: Wednesday, November 13, 2013 6:09 AM<br>
To: <a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank">llvm-commits@cs.uiuc.edu</a><br>
Subject: (Very) small patch for the jit event listener<br>
<br>
Hi all,<br>
<br>
We have a small problem for vmkit. We rely on the JITEventListener to register the safepoints generated for the garbage collector, and for that purpose, we have to use the JITCodeEmitter (the<br>
MachineCodeEmitter) that was used to generate the MachineFunction in order to find the physical address of the safepoints (aka, the MCSymbols). A long time ago, it was not a problem as the JIT class was in the llvm interface, but today, the header is hidden
inside the lib directory and not installed by llvm. Currently, we directly use this header, but it means that during the compilation of vmkit, we need the sources of llvm. But, as we are currently developing a debian package of vmkit, we would like to avoid
the installation of the llvm sources to compile vmkit.<br>
<br>
So, I made a small patch that just adds a new MachineCodeEmitter field in JITEvent_EmittedFunctionDetails and fill it in JITCodeEmitter. As the patch only adds a new field in the JITEvent_EmittedFunctionDetails, it should not break anything. At least, my llvm
and my vmkit are still running :) (by the way, I had to execute a make clean before recompiling llvm because I think that a dependency is missing)<br>
<br>
As it is my first patch, I hope that I have used the llvm coding style...<br>
<br>
See you,<br>
Gaël<br>
<br>
<br>
<br>
<br>
<br>
<br>
--<br>
-------------------------------------------------------------------<br>
Gaël Thomas, Associate Professor, UPMC<br>
<a href="http://pagesperso-systeme.lip6.fr/Gael.Thomas/" target="_blank">http://pagesperso-systeme.lip6.fr/Gael.Thomas/</a><br>
-------------------------------------------------------------------<br>
<br>
_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><u></u><u></u></p>
</blockquote>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div></div></div>
</div>
</blockquote></div><br></div>