[LLVMdev] Using MCJIT in a dynamic REPL environment

[Yaron Keren]

The new MCJIT is module-oriented, like a classic compiler+linker (which it
is) while the old JIT is function-oriented.

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.

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  ?

What were the reasons EH and Debug modules were duplicated in JIT rather
then reused from lib/MC?

Maybe move the barebones JIT function-level functionality (stub functions)
into MCJIT ?

Yaron



2013/10/30 Jim Grosbach <grosbach at apple.com>

> Sure, that makes a lot of sense. The implementation details may get
> tricky, of course, but the concept is great.
>
> -Jim
>
> On Oct 30, 2013, at 12:20 PM, Yaron Keren <yaron.keren at gmail.com> wrote:
>
> > Hi,
> >
> > 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.
> >
> > With the JIT it's quite simple to unload and replace functions due to
> the stubs (JMP instructions) that redirect the actual function calls.
> >
> > With the MCJIT the equivalent implementation would be:
> >
> > 1) Place one function per IR module.
> > 2) Load (compile) IR modules into Object code and cache the objects.
> > 3) Upon running finalize (link) everything and run.
> > 4) If a function is changed, kill its module and reload it. Then use the
> cached objects and finalize everything.
> >
> > Compared with the JIT, 4) isn't scalable, since it requires relinking of
> possibly  many modules due to the change of just one function.
> >
> > 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.
> >
> > We'd also need a way to modify the EH and Debug information without
> recreating it.
> >
> > That would provide a reasonable replacement for the JIT flexibility in
> handling functions. Does it make any sense?
> >
> > Yaron
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131030/774a1921/attachment.html>