[LLVMdev] [RFC] MCJIT usage models

[Philip Reames]

On 12/9/13 11:08 AM, Kaylor, Andrew wrote:
>
> Below is an outline of various usage models for MCJIT that I put 
> together based on conversations at last month's LLVM Developer 
> Meeting.  If you're using or thinking about using MCJIT and your use 
> case doesn't seem to fit in one of the categories below then either I 
> didn't talk to you or I didn't understand what you're doing.
>
> In any case, I'd like to see this get worked into a shape suitable for 
> inclusion in the LLVM documentation.  ...
>
Thank you for doing this.  It's a good step to take and will help both 
users and maintainers of the MCJIT infrastructure.
>
> 4. Hot function replacement
>
>     - client uses MCJIT to optimize frequently executed code
>
>     - example: WebKit
>
>     - compilation time is not critical
>
>     - execution speed is critical
>
>     - steady state memory consumption is very important
>
>     - client handles pre-JIT interpretation/execution
>
>     - MCJIT instances may be created as needed
>
>     - custom memory manager transfers code memory ownership after 
> compilation
>
>     - MCJIT instance is deleted when no longer needed
>
>     - client handles function replacement and lifetime management
>
This is our currently planned use.

A couple of extra requirements:
- Linking of declared function names to specific addresses provided at 
generation time (e.g. getPointerToNamedFunction)
- Ability to place generated code at a specific address (either via 
allocation control, or relocation)
- Multiple compiler threads (using different instances of MCJIT) without 
underlying shared state protected by locks.  -- Mentioned elsewhere, 
just making it explicit for this use case.
- Internal errors are cleanly reported to API consumer with internal 
state restored to well defined "safe" state -- I'm aware this is very 
much wishful thinking at the moment, but being able to recover from bad 
compiles would be very nice to have.  We're likely to explore external 
sandboxing as well, but having good library support would be useful.
- Debugging Support:
   - IR is verified before optimization (by default or by option)
   - IR can be easily dumped during various optimization passes for 
debugging.  Assembly can be dumped.

A clarification question:
- Do you see MCJIT having any role in inlining decisions in this mode?  
If so, there's a fair amount of extra support around inline decision 
tracking to support external lifetime policies.  We don't strictly need 
this, but long term it would simplify our out of code tree substantially.

A few things that are currently on our wish list, but that we haven't 
actually gotten to yet:
- Accurate debug information (with full stack traces) - this has been 
discussed previously on the list.  Not sure it would require much extra 
from the MCJIT infrastructure.
- Profile guided optimization (e.g. guarded inlining, type profiles for 
call sites, edge counters, etc..) - We haven't gotten to the point of 
considering what parts of this would be in tree vs language specific and 
thus external.  It's also unclear how much this would effect MCJIT 
directly.
- Inline call caching - likely using the patch point mechanism 
introduced by the Webkit guys.
- We've thrown around ideas of a compile server process.  This would 
involve constraints similar to your (2).  This hasn't made it past brain 
storming yet.

Yours,
Philip

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131210/dabc682b/attachment.html>