llvm dev - Oct 2013 - [LLVMdev] Using MCJIT in a dynamic REPL environment

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131030/eaa52435/attachment.html>

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

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>