[LLVMdev] (Very) small patch for the jit event listener

[Yaron Keren]

Hi Andy,

We had previous discussions about this, I'd like to state more exactly what
features would make MCJIT a replacement for the JIT.
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.

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 :

1) Automatic module splitting into function-modules.
2) Module delete: from module list, from linker namespace, machine code
unload, unregister EH and debuginfo.
3) Stub functions.
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.
5) Module addition should register EH and debuginfo (this is not done with
current JIT but while at it...).

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.

Until MCJIT has this kind of flexibility, I hope the JIT would be kept
alive.

Yaron






2013/11/13 Kaylor, Andrew <andrew.kaylor at intel.com>

> Hi Gaël,
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> (BTW, it's probably appropriate to move further discussion to the LLVMDev
> list rather than llvm-commits.)
>
> Thanks,
> Andy
>
>
> -----Original Message-----
> From: llvm-commits-bounces at cs.uiuc.edu [mailto:
> llvm-commits-bounces at cs.uiuc.edu] On Behalf Of Gaël Thomas
> Sent: Wednesday, November 13, 2013 6:09 AM
> To: llvm-commits at cs.uiuc.edu
> Subject: (Very) small patch for the jit event listener
>
> Hi all,
>
> 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
> 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.
>
> 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)
>
> As it is my first patch, I hope that I have used the llvm coding style...
>
> See you,
> Gaël
>
>
>
>
>
>
> --
> -------------------------------------------------------------------
> Gaël Thomas, Associate Professor, UPMC
> http://pagesperso-systeme.lip6.fr/Gael.Thomas/
> -------------------------------------------------------------------
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131113/5040de2e/attachment.html>