[LLVMdev] Caching ExecutionEngine / MCJIT

[Paweł Bylica]

Thank you for all responses. I did as suggested and everything works as I
wanted to.

There is however one small performance issue I've spotted. To check if a
function has been JITed and is already in memory I need to use
getFunctionAddress, and it does section relocations every time
(via finalizeLoadedModules()). I would like to use getSymbolAddress from
MCJIT but is not accessible by ExecutionEngine interface.

On Sun, Jan 4, 2015 at 9:11 PM mahesh ravishankar <
mahesh.ravishankar at gmail.com> wrote:

> My response would be similar to some of the previous replies. In my
> experience with MCJIT, the best way is to have one instance of the
> ExecutionEngine. Everytime you create a new llvm IR Module, add to the
> MCJIT ExectionEngine using addModule . It would be a good idea to create
> unique function names everytime you create a new llvm IR Module (I dont
> know what happens if there is a clash).
> With respect to hashing, I would implement hashing from your high-level
> code to the function generated outside of the MCJIT Execution Engine. Once
> you get the function name from your hash function you can get the function
> address using getFunctionAddress.
>
> On Mon, Dec 29, 2014 at 10:36 AM, Philip Reames <listmail at philipreames.com
> > wrote:
>
>>
>> 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 listLLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.eduhttp://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>
>
>
> --
> Mahesh
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150304/a59ebf59/attachment.html>