<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">One of the biggest problems with the old JIT engine is that no one is actively maintaining it and it doesn’t work everywhere. (I suppose that’s actually two
problems.)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">As for your suggestion about stubs in MCJIT, that might not even be terribly difficult to get working, at least for the local case, though as Jim says there
are some lurking complications. MCJIT currently puts a wrapper around the client memory manager to provide linking between modules. It would be a small matter to have that linking code produce stubs rather than returning the direct address of the function
to be linked to. That would also be a nice step toward lazy compilation.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Ideally, the client memory manager should allocate memory for the stubs, but I don’t think it could use the same mechanisms that are in the interface today
because the page permissions would need to be changed whenever a new stub was added. MCJIT should be responsible for writing the stubs. One issue to be solved would be how to handle the case where one thread tried to call a stubbed function while another
thread was adding a stub. Supporting remote execution clients would also be complicated.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">In any case, this should not be the default behavior for MCJIT, as I wouldn’t want to burden clients with the stub mechanism unless they specifically indicated
that they need it.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">-Andy<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></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:yaron.keren@gmail.com]
<br>
<b>Sent:</b> Wednesday, October 30, 2013 12:39 PM<br>
<b>To:</b> Jim Grosbach<br>
<b>Cc:</b> <llvmdev@cs.uiuc.edu>; Kaylor, Andrew<br>
<b>Subject:</b> Re: [LLVMdev] Using MCJIT in a dynamic REPL environment<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">The new MCJIT is module-oriented, like a classic compiler+linker (which it is) while the old JIT is function-oriented. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">If I understand correctly, the main problems with the old JIT were the duplication of the debug information code and EH code (both gone now). Moreover, if we ignore the lazy evaluation mechanism then the current JIT is actually quite simple
module. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Would it be possible to keep such barebones JIT (without lazy evaluation which does add to the complexity) and get back the Debug and EH information but from the existing MCDwarf framework ? <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">What were the reasons EH and Debug modules were duplicated in JIT rather then reused from lib/MC?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Maybe move the barebones JIT function-level functionality (stub functions) into MCJIT ?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Yaron<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">2013/10/30 Jim Grosbach <<a href="mailto:grosbach@apple.com" target="_blank">grosbach@apple.com</a>><o:p></o:p></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">Sure, that makes a lot of sense. The implementation details may get tricky, of course, but the concept is great.<br>
<br>
-Jim<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal"><br>
On Oct 30, 2013, at 12:20 PM, Yaron Keren <<a href="mailto:yaron.keren@gmail.com">yaron.keren@gmail.com</a>> wrote:<br>
<br>
> Hi,<br>
><br>
> I'm trying to transition from the JIT to MCJIT. The requirements are fast response time and dynamic unloading/replacement of modified functions. Lazy evaluation is *not* required: I expect all functions to be present at runtime or else an error is fine.<br>
><br>
> With the JIT it's quite simple to unload and replace functions due to the stubs (JMP instructions) that redirect the actual function calls.<br>
><br>
> With the MCJIT the equivalent implementation would be:<br>
><br>
> 1) Place one function per IR module.<br>
> 2) Load (compile) IR modules into Object code and cache the objects.<br>
> 3) Upon running finalize (link) everything and run.<br>
> 4) If a function is changed, kill its module and reload it. Then use the cached objects and finalize everything.<br>
><br>
> Compared with the JIT, 4) isn't scalable, since it requires relinking of possibly many modules due to the change of just one function.<br>
><br>
> I wonder if it's possible to use the stub function mechanism in order to save the relinking step. The dynamic linker can resolve everything to the stub functions that jump to real functions but then the function implementation could be replaced in a new module
without relinking all other modules but itself only.<br>
><br>
> We'd also need a way to modify the EH and Debug information without recreating it.<br>
><br>
> That would provide a reasonable replacement for the JIT flexibility in handling functions. Does it make any sense?<br>
><br>
> Yaron<br>
><o:p></o:p></p>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt">> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">
http://llvm.cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><o:p></o:p></p>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</body>
</html>