[LLVMdev] Caching ExecutionEngine / MCJIT

[Philip Reames]

On 12/29/2014 05:23 AM, Paweł Bylica wrote:
> Hello everyone,
>
> I need some advises about (re)using ExecutionEngine with MCJIT as a 
> driver. I'm developing a service that receives a piece of high-level 
> code, compiles it into LLVM IR function "main" and uses MCJIT to 
> execute the function.
>
> It can happen that the same piece of code is sent to the service many 
> times. I would like to cache the results (keep generated machine code 
> alive) and do just the execution step. But I'm having problems with that.
>
> My first attempt was to cache ExecutionEngine instance and function 
> address (from getFunctionAddress() method). Executing cached function 
> second time crashes the process.
>
> I noticed that doing getFunctionAddress() each time helps a bit. There 
> is no crash but results produced by executed function are incorrect 
> and there are probably some memory access violations going on.
>
> Using the same function name for each code is probably a bad idea in 
> case of MCJIT, so I changed the names to some random value. However, 
> it did not help in any of previous problems.
>
> I thinking about using single instance of ExecutionEngine or share 
> Memory Manager. Can I get any advice on that?
My suggestion would be to use a single long lived instance of EE and 
MM.  Use some hashing mechanism to map your high level requests to a 
unique key.  If you've already generated it, just reuse the existing 
code.  Otherwise, create a new module, add it to the EE, and compile.

This will cause you to "leak" memory for code that isn't being reused.  
I don't know of a good solution to that within the framework of MCJIT, 
but you can get something reasonable by simply recreating your EE and MM 
instances every N (10000?) compiles. Until you have something like that 
working, I won't worry about trying to improve the memory caching strategy.

p.s. You can also look at using the on-disk cache capabilities.  I have 
never used that and have no idea how useful it is.
> Happy New Year,
> Paweł Bylica
>
>
>
>
> _______________________________________________
> 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/20141229/153252f8/attachment.html>