[LLVMdev] Using MCJIT in a dynamic REPL environment

[Kaylor, Andrew]

One of the biggest problems with the old JIT engine is that no one is actively maintaining it and it doesn't work everywhere.  (I suppose that's actually two problems.)

As for your suggestion about stubs in MCJIT, that might not even be terribly difficult to get working, at least for the local case, though as Jim says there are some lurking complications.  MCJIT currently puts a wrapper around the client memory manager to provide linking between modules.  It would be a small matter to have that linking code produce stubs rather than returning the direct address of the function to be linked to.  That would also be a nice step toward lazy compilation.

Ideally, the client memory manager should allocate memory for the stubs, but I don't think it could use the same mechanisms that are in the interface today because the page permissions would need to be changed whenever a new stub was added.  MCJIT should be responsible for writing the stubs.  One issue to be solved would be how to handle the case where one thread tried to call a stubbed function while another thread was adding a stub.  Supporting remote execution clients would also be complicated.

In any case, this should not be the default behavior for MCJIT, as I wouldn't want to burden clients with the stub mechanism unless they specifically indicated that they need it.

-Andy

From: Yaron Keren [mailto:yaron.keren at gmail.com]
Sent: Wednesday, October 30, 2013 12:39 PM
To: Jim Grosbach
Cc: <llvmdev at cs.uiuc.edu>; Kaylor, Andrew
Subject: Re: [LLVMdev] Using MCJIT in a dynamic REPL environment

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<mailto: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<mailto: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<mailto: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/666a1dda/attachment.html>