[PATCH][llvm-c] Expose MC JIT

[Filip Pizlo]

Responding to both David and Amara...

On Apr 23, 2013, at 1:06 AM, David Tweed <david.tweed at arm.com> wrote:

> Hi,
>  
> It's great that you're doing high-quality work on getting MC-JIT into a much better shape!
>  
> | More broadly, getting MCJIT into a better shape is on my critical path, as well.  See: https://bugs.webkit.org/show_bug.cgi?id=112840.  I'd like to help out with the de-sloppiness-ifying of it, so I'd like to understand better what the end goal is.  I
> |already know that I want to control memory management, cache management, and page permissions myself as a client, and preferably I want to accomplish this by supplying my own RuntimeDyld (or JITMemoryManager).  I also know that I'll want to
> |improve error tolerance - for example in case of memory allocation failure (honestly, I haven't investigated this much, so this may already be supported - I just don't see how through the API).  So, I'm particularly interesting in seeing how to get the
> |MCJIT into a great shape while supporting both the currently-envisioned use cases in LLVM and its other clients, and also the way that WebKit will use it!  This should be fun. :-)
>  
> Can I just ask why you want to control cache management and page permissions within your client code? (This is a genuine question: I don't quite see what it gets you, but it'd be interesting to know.)

Are you asking why we have our own JIT infrastructure that is independent of LLVM, or specifically why our independent JIT infrastructure choses to not call into LLVM for page/cache invalidation?

The fact that we want to do cache/page management ourselves is a consequence of us having our own memory manager and our own JITs.  The fact that we will continue to handle cache/page invalidation ourselves is a consequence of us wanting to keep our memory manager even as we use LLVM for our top-tier JIT, because we believe that it is better-suited to our needs than the memory managers that the LLVM provides.

I can give you a more detailed answer on why we would like to keep this memory manager - but I figured I'd ask for clarification before writing that up.

> One of my worries about delegating cache management is that it can be a source of very intermittent bugs: if you don't cache invalidate on the transition from data to code on ARM, 99% of the time everything works...

We've had JITs in WebKit for X86 (32 and 64), ARM (traditional and thumb2), and other architectures for years.  I'm pretty sure we know how to do this.

I buy the argument that LLVM's JIT API should by default do the right thing for you.  But that doesn't mean we can't do it right ourselves.  We do handle this on our own right now, and I believe that we do get it right.  If you have specific reasons to believe that WebKit mishandles cache permissions on ARM, then I suggest you file a bug on http://bugs.webkit.org.

> I can't at the moment see the advantage of not delegating that to a core part of LLVM that "knows what it's doing better than I do".
>  
> Cheers,
> Dave

On Apr 23, 2013, at 3:10 AM, Amara Emerson <amara.emerson at arm.com> wrote:

> Agreed here about getting at least some default “do the right thing” cache management into core LLVM. This is such an easy issue to miss, especially for people who don’t know about the architectural memory model intricacies and just want the API to do what it says. So much so, that our own “reference” client, lli, was silently failing to handle it correctly until a few months ago.

Agreed that the LLVM should have the ability to do the right thing by default.  But are you suggesting that the LLVM should also *not* expose the ability to do this manually?  That would be strange.

>  
> At the same time we need an interface that gives clients fine grain control over memory management and page permissions etc. I don’t like the ownership model as it currently stands, with ExecutionEngine eagerly destroying the memory manager object. This makes people write ugly workarounds to maintain control over their JITed code while trying to get around the lack of multiple modules support. IMO, the JIT compiler and memory manager are related, but mostly orthogonal, components.

I actually think that this model is great, for us.  We don't want to keep the ExecutionEngine around after we have emitted code, and that code is handed over to WebKit.  Our approach will work as follows:

1) optimizing JIT gets invoked
2) generates LLVM IR
3) creates MCJIT, with our own "memory allocator" as a callback - this callback is designed for stealing the memory from LLVM when done
4) runs LLVM phases
5) gets a pointer to function
6) destroys the MCJIT and all of the IR, and the memory allocator callback
7) the code starts running, and the code object is now owned by our allocator.

I don't see a viable alternative to this approach no matter what LLVM's API looked like: we don't want to pay the memory footprint of keeping around LLVM data structures if we are not currently JITing code.

>  
> Amara


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130423/b913d720/attachment.html>