<div dir="rtl"><div dir="ltr">Gael, anyone who dynamically un/loads functions will face these problems.</div><div dir="ltr">You have certainly gone much further than me trying to solve them!<br></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/11/14 Gaël Thomas <span dir="ltr"><<a href="mailto:gael.thomas@lip6.fr" target="_blank">gael.thomas@lip6.fr</a>></span></div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Andrew, hi all,<br>
<br>
I already saw that the old jit was (almost) deprecated. So, I'm<br>
currently playing with the new jit and it's look very interesting.<br>
(I'm working locally and I haven't pushed anything new on VMKit<br>
because I'm also changing a little the design vmkit). For the moment,<br>
MCJIT does not work with VMKit (but I haven't yet tested the<br>
safepoint/stackmap patch), I don't know if it comes from what I'm<br>
doing or if something is still missing in MCJIT.<br>
<br>
Sorry, my mail will be too long, but I want first to explain what I'm<br>
currently doing and then open the discussion to explain what I would<br>
like to see in MCJIT :) Of course, I can help to develop something or<br>
to give feed back, I'm hardly working on vmkit currently and I have<br>
time to spend on that (but I'm far from an expert in compilation<br>
stuffs!).<br>
<br>
Basically, I want to compile lazily my functions (we have a Java<br>
virtual machine built upon vmkit and compiling all the rt.jar during<br>
the bootstrap is not very realistic:)). So, by lazy compilation, I<br>
mean that I want to compile (and even resolve) a function only when it<br>
is used. For example, during the compilation of<br>
void f() { g() }<br>
I don't want to compile g(). I will only compile g() when it will be called.<br>
<br>
For the moment, I use a home-made stub (I have attached the asm code,<br>
it can give you some ideas if you plan to integrate a stub generator<br>
able to perform dynamic dispatch like virtual call in c++) because<br>
MCJIT does not provide this facility. So, for each function, I define<br>
a module. In each module, I have to define the runtime function (such<br>
as gcmalloc, throwException and this kind of functions). They are<br>
defined in a separated runtime module populated during the bootstrap.<br>
I have thus this picture<br>
<br>
MCJIT<br>
|----------------------------------------------------------<br>
| | |<br>
Runtime module module for f module for g<br>
<br>
When I see that I need g during the compilation of f, I define an<br>
external symbol g in f's module and I add a global mapping between g<br>
and its stub in MCJIT. Everything works perfectly in the old JIT, so<br>
the code is correct in this case. The problem that I face with<br>
multiple modules in the old JIT is that the symbol g defined in f's<br>
module and the symbol g defined in g's module are not the same, I thus<br>
have to define multiple symbol in the old JIT for the same entity,<br>
which is far from perfect. Anyway, it works.<br>
<br>
With MCJIT, I can call f from my C++ code (relatively easy as f is<br>
defined in its own module), the stub of g is called and I can<br>
generate its code (which use other functions). But I can not find a<br>
way to compile g and to update the mapping between g and the new<br>
function pointer. When I use recompileAndRelinkFunction, I see that it<br>
is not implemented in MCJIT, and when I use getFunctionPointer, I<br>
obtain.... a null pointer? I have not investigated further, but<br>
probably, having two symbols g in the same MCJIT does not work. And I<br>
don't see what I can do at this step? Maybe that I have missed<br>
something?<br>
<br>
Otherwise, I already predict that I will also have one big problem<br>
latter: I would like to inline functions from the runtime module in f<br>
or g, and I would like to inline the code of an already compiled<br>
function h in g. So, I would like to inline functions that comes from<br>
different modules. It means that I would like to see MCJIT working<br>
like an llvm::Linker, able to resolve the h symbol during the<br>
compilation of g. And for the moment, as MCJIT can not see that the g<br>
defined in f's module and the g defined in g's module represent the<br>
same function, I think that I will have a problem latter.<br>
<br>
So, for the moment, I'm a little bit stuck with MCJIT. Something that<br>
could be really useful could be a mcjit that acts as a linker. If<br>
MCJIT could have a map like this (I give a pseudo-c++ code)<br>
<br>
class FnDescriptor {<br>
StringRef name;<br>
FunctionType fnType;<br>
LinkageType linkage;<br>
};<br>
<br>
class FnState {<br>
llvm::Module* definedModule;<br>
/* maybe a llvm::ObjectImage* ? */<br>
List<RelocationTable*>* users,<br>
void* currentPointer<br>
};<br>
<br>
map<FnDescriptor, FnState><br>
<br>
it could be really useful. Let's imagine the same scenario with f that<br>
calls g while g is not yet compiled. At the beginning of this<br>
scenario, "g" "void ()" could simply be associated to a FnState with<br>
<br>
<null, List<>, stubForG>.<br>
<br>
After f's compilation, it could be something like that<br>
<br>
<null, List<RelocationTable-of-module-f>, stubForG>.<br>
<br>
And after the compilation of g, something like<br>
<br>
<moduleOfG, List<Reloc-f, Reloc-g>, compiledCode-of-g><br>
<br>
with the relocation entries updated?<br>
<br>
Otherwise, for safepoints, and for exception tables, it could be also<br>
really useful to install call backs to let VMKit manages them itself<br>
(but it's maybe provided by the safepoint/patchpoint patch?)? (with<br>
something that can make the association between a MCSymbol and it's<br>
actual address of course :) )<br>
<br>
See you!<br>
Gaël<br>
<br>
PS: by the way, Yaron, we currently face almost the same problems<br>
<br>
<br>
2013/11/13 Yaron Keren <<a href="mailto:yaron.keren@gmail.com">yaron.keren@gmail.com</a>>:<br>
<div class="HOEnZb"><div class="h5">> Hi Andy,<br>
><br>
> We had previous discussions about this, I'd like to state more exactly what<br>
> features would make MCJIT a replacement for the JIT.<br>
> After putting significant effort trying to move to MCJIT, I'm currently back<br>
> with the JIT. This is in a REPL environment where functions are added and<br>
> removed dynamically and response time is important. The issue is the legacy<br>
> JIT provides great flexibility for this use case which is currently missing<br>
> from MCJIT because of their very different design and goals.<br>
><br>
> With JIT, you can modify Function(s) in an already-compiled Module, unload<br>
> the machine code and the JIT will automatically recompile and relink the<br>
> function next time it is called. To make MCJIT work like that it would need<br>
> at least :<br>
><br>
> 1) Automatic module splitting into function-modules.<br>
> 2) Module delete: from module list, from linker namespace, machine code<br>
> unload, unregister EH and debuginfo.<br>
> 3) Stub functions.<br>
> 4) Relinking with stub functions so that new modules are relinked without<br>
> changing already-finalized modules. This is critical to response time as you<br>
> may change just one function out of 1000.<br>
> 5) Module addition should register EH and debuginfo (this is not done with<br>
> current JIT but while at it...).<br>
><br>
> REPL environments using the LLVM JIT would likely encounter great difficulty<br>
> moving to the current MCJIT without the above. 1) could be done by the<br>
> programmer but the a helper function should provide this service. 2)-4)<br>
> could be done only in the MCJIT. 5) is a bonus.<br>
><br>
> Until MCJIT has this kind of flexibility, I hope the JIT would be kept<br>
> alive.<br>
><br>
> Yaron<br>
><br>
><br>
><br>
><br>
><br>
><br>
> 2013/11/13 Kaylor, Andrew <<a href="mailto:andrew.kaylor@intel.com">andrew.kaylor@intel.com</a>><br>
>><br>
>> Hi Gaël,<br>
>><br>
>> I'm not familiar enough with the details of the old JIT engine and its<br>
>> event interface to comment on whether or not your changes are appropriate,<br>
>> but I'm not sure anyone is so the patch is probably OK as is. I don't see<br>
>> any obvious problems with it.<br>
>><br>
>> However, your description of the changes raises a bigger issue in my mind.<br>
>> I'm not sure if you are aware of this, but we're planning to deprecate the<br>
>> old JIT engine in a future release -- possibly as soon as LLVM 3.5. In<br>
>> order to do so we need to make sure the MCJIT engine is capable of meeting<br>
>> the needs of current JIT users, and I'm not sure we've got your case fully<br>
>> covered yet.<br>
>><br>
>> Can you tell me a little bit more about the details of how you are using<br>
>> the JIT engine? I'm putting together a document describing various models<br>
>> for MCJIT use and if your model isn't covered by one of the cases I've got<br>
>> now I'd like to add it.<br>
>><br>
>> Also, have you looked at the recently added Stackmap and Patchpoint<br>
>> intrinsics. Without knowing a lot about either your case or those<br>
>> intrinsics, I think that there may be a possible match there. The thing<br>
>> that raised a red flag for me in your message was that MCJIT doesn't<br>
>> maintain mappings between the generated code and the LLVM classes from which<br>
>> it is produced, so we'll probably need a different way to handle your<br>
>> safepoints.<br>
>><br>
>> (BTW, it's probably appropriate to move further discussion to the LLVMDev<br>
>> 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">llvm-commits-bounces@cs.uiuc.edu</a><br>
>> [mailto:<a href="mailto:llvm-commits-bounces@cs.uiuc.edu">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">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<br>
>> register the safepoints generated for the garbage collector, and for that<br>
>> purpose, we have to use the JITCodeEmitter (the<br>
>> MachineCodeEmitter) that was used to generate the MachineFunction in order<br>
>> to find the physical address of the safepoints (aka, the MCSymbols). A long<br>
>> time ago, it was not a problem as the JIT class was in the llvm interface,<br>
>> but today, the header is hidden inside the lib directory and not installed<br>
>> by llvm. Currently, we directly use this header, but it means that during<br>
>> the compilation of vmkit, we need the sources of llvm. But, as we are<br>
>> currently developing a debian package of vmkit, we would like to avoid the<br>
>> installation of the llvm sources to compile vmkit.<br>
>><br>
>> So, I made a small patch that just adds a new MachineCodeEmitter field in<br>
>> JITEvent_EmittedFunctionDetails and fill it in JITCodeEmitter. As the patch<br>
>> only adds a new field in the JITEvent_EmittedFunctionDetails, it should not<br>
>> break anything. At least, my llvm and my vmkit are still running :) (by the<br>
>> way, I had to execute a make clean before recompiling llvm because I think<br>
>> 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">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><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>
</div></div></blockquote></div><br></div>