ORC JIT - Can modules independently managed with one LLJIT instance?

Project Infrastructure LLVM Dev List Archives
1

Hello everyone and Lang,

I have another design or “how-to” question about the ORC JIT. Sorry for having so many about them, to me this is a really complicated yet fascinating subject…

How would I design an ORC JIT with the following requirements?

At any time it should be possible to load a LLVM Module, every Module is independent and is not allowed to be linked with the other modules, every module can be removed at any time.

My first idea was to have an ORC JIT for every module I load, but then I wondered if I could use a single ORC JIT for it.

So, I would create an ORC JIT:

  • using llvm::orc::LLJITBuilder

  • configurating it

  • adding a custom memory manager that requests the entire memory size

Then I would call “getMainJITDylib” and fill it with symbols that are valid for every module:

  • adding printf, strlen, usw.

Now when I get a request to load a module:

  • load module

  • get symbols I want to look up

  • create new DyLib and add module to that

Now I would do a lookup on that module, plus the main module to get symbol addresses and stuff

If a new module is added, it goes to a new DyLib as well and so on.

2

Hi Bjoern,

Sounds like you want the removable code feature that’s under development in the orcv1-removal branch of https://github.com/lhames/llvm-project.git. I will be aiming to merge this work back into the mainline some time in the next couple of weeks.

I have not added a “removeJITDylib” method to ExecutionSession with this feature yet, but will try to design and publish that tomorrow. Then you should be able to do exactly what you want.

In the new system you can also perform fine grained removal: It is possible to track and remove individual modules from within a JITDylib. For an example of this see: https://github.com/lhames/llvm-project/blob/7ec9f8930f68760953a483157e010d0ff88285cd/llvm/examples/Kaleidoscope/BuildingAJIT/Chapter1/toy.cpp#L1148, from lines 1148 to line 1161.

Also a related but different question:
When using llvm::parseIRFile I need to pass it a LLVMContext - should this be a unique one for every module I pass or can I use a global one?

It depends on whether you want to be able to compile concurrently in the JIT process. If you do want to compile concurrently then each module should get its own context. If you are happy to stick to single threaded compilation you can load all modules on the same context, potentially saving some memory.

– Lang.