<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hi Kavon,<div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">In my case, the process is already running with one version of the program code, and another thread is hot-patching functions with dynamically recompiled versions (I've extended XRay for this). Thus, I actually want to avoid reinitializing or creating new versions of globals for the Dylib output by ORC and instead link with the ones in-process.</blockquote><div> </div></div></div><div>Yep. That should be fine. In your use-case you will want to split your globals and functions into different modules, and create new JITDylibs with no initializers to hold any functions whose memory you would like to be able to reclaim later. Then you can dlclose those JITDylibs to reclaim the memory for the contained functions.</div><div><br></div><div>Actually, if my current prototype pans out then there might be an even better solution for your use case: I'm hoping to provide fine-grained removal of modules from within a JITDylib (without removing the whole JITDylib). The advantage of this is that it's easier to reason about (functions can go in the conceptually "correct" JITDylib, even if you want to remove them later) and less expensive (It's more expensive to maintain one JITDylib per function than to maintain one JITDylib with many functions).</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">In my case, the process is already running with one version of the program code...</blockquote><div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">My plan for achieving this is to externalize all internal globals in the original bitcode before JIT compilation and hope that the ORC dynamic linker handles the rest automatically.</blockquote></div></div><div><br></div><div>Do you mean that you want to take the IR for the original version, turn the global definitions into declarations, then try to JIT it? This will work for globals that had external linkage in the original program, but may fail for local/private variables for two reasons:</div><div><br></div><div>(1) ORC will usually try to find the addresses of the external globals by calling dlsym (assuming you're using the DynamicLibrarySearchGenerator), and this will not find internal/private symbols. If Xray maintains a side table of internal symbol addresses you could work around this by extending lookup to search the side table.</div><div><br></div><div>(2) The optimizers and linker are free to rename / remove / dead-strip private globals depending on how they are used. For example, on my machine the following results in an empty data section (Result gets SCCP'd away):</div><div><br></div><div><font face="monospace">static int Result = 42;</font></div><div><font face="monospace">int getResult() {</font></div><div><font face="monospace">  return Result;</font></div><div><font face="monospace">}</font></div><div><br></div><div>So if you turned Result into a declaration and then tried to JIT the function at a lower optimization level you would get a missing definition error. In this case, one workaround might be to consult the side table from (1) (if you have it), and only turn the global definition into a declaration if the table indicates that there is an existing definition. If there isn't you could promote your definition to extern linkage and have it serve as the definition going forward. </div><div><br></div><div>Cheers,</div><div>Lang.</div><div><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Aug 23, 2019 at 9:18 AM Kavon Farvardin <<a href="mailto:kavon@farvard.in">kavon@farvard.in</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="text-align:left;direction:ltr"><div>Thanks for the reply, Lang! I really appreciate the effort you've been putting into the JIT infrastructure and that you take the time to answer lots of questions about it on the mailing list.</div><div><br></div><div><blockquote type="cite" style="margin:0px 0px 0px 0.8ex;border-left-width:2px;border-left-style:solid;border-left-color:rgb(114,159,207);padding-left:1ex"><div dir="ltr"><div>I am working on initializer/destructor support that will allow us to perform the equivalent of dlopen/dlclose on JITDylibs.</div></div></blockquote><br></div><div>In my case, the process is already running with one version of the program code, and another thread is hot-patching functions with dynamically recompiled versions (I've extended XRay for this). Thus, I actually want to avoid reinitializing or creating new versions of globals for the Dylib output by ORC and instead link with the ones in-process.</div><div><br></div><div>My plan for achieving this is to externalize all internal globals in the original bitcode before JIT compilation and hope that the ORC dynamic linker handles the rest automatically.</div><div><br></div><div>Cheers,</div><div>Kavon</div><div><br></div><div>On Thu, 2019-08-22 at 14:23 -0700, Lang Hames wrote:</div><blockquote type="cite" style="margin:0px 0px 0px 0.8ex;border-left-width:2px;border-left-style:solid;border-left-color:rgb(114,159,207);padding-left:1ex"><div dir="ltr">Hi Kavon,<div><br></div><div>Unfortunately we don't have a good way to do this at the moment, short of maintaining multiple execution sessions (analogous to the way you maintained multiple ExecutionEngines).</div><div><br></div><div>I am working on initializer/destructor support that will allow us to perform the equivalent of dlopen/dlclose on JITDylibs. Once that support is available I think it would be a good fit for your use case. Unfortunately I think it is still a few months away.</div><div><br></div><div>Cheers,</div><div>Lang.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Aug 19, 2019 at 3:38 PM Kavon Farvardin via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote type="cite" style="margin:0px 0px 0px 0.8ex;border-left-width:2px;border-left-style:solid;border-left-color:rgb(114,159,207);padding-left:1ex"><div style="text-align:left;direction:ltr;word-wrap:break-word;line-break:after-white-space"><div>Hi,</div><div><br></div><div>I'm working on a runtime autotuner that utilizes ORCv2 JIT (I'm closely tracking tip-of-tree), so linking new object files and patching in the new function(s) will happen frequently. </div><div><br></div><div>One of the concerns my runtime system has is the ability to do one of the following: (1) replacement of the contents of a JITDylib with a new object file [to provide semi-space GC-style reclaiming], (2) the outright removal of a JITDylib.</div><div><br></div><div>Right now, I have one ExecutionSession instance for my linker and am creating a new JITDylib for each object file that I'd like to link in. There doesn't appear to be a corresponding ExecutionSession::removeJITDylib(..) method, so I'm wondering: how do I reclaim the memory for code that I've linked in previously but no longer need?</div><div><br></div><div>When using MCJIT, I would reclaim this memory by destroying the ExecutionEngine that was created for each "JITDylib". Should I do the same with ExecutionSessions?</div><div><br></div><div>For reference, here's the short bit of code I'm playing with for linking with ORC: </div><div><a href="https://github.com/halo-project/llvm/blob/master/compiler-rt/lib/halomon/DynamicLinker.h#L55" target="_blank">https://github.com/halo-project/llvm/blob/master/compiler-rt/lib/halomon/DynamicLinker.h#L55</a></div><div><br></div><div>Thanks,</div><div>Kavon</div></div>
_______________________________________________<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="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>
</blockquote></div>
</blockquote></div></div></div></div></div>