[llvm-commits] [PATCH] [Review request] Clean-up of MCJIT object ownership

[Kaylor, Andrew]

Hi Jim,

I don't think my patch changes anything with regard to remote target execution.  It just changes the way memory buffers are encapsulated.

I believe it would work like this:


1.       Client creates MCJIT engine, passing in a Module and a JITMemoryManager object of its choice

2.       Client triggers compilation, probably by requesting a function pointer

a.       MCJIT creates a new ObjectBufferStream object for use in code generation

b.      MCJIT runs MC code generation, populating the ObjectBufferStream memory

c.       MCJIT calls RuntimeDyld::loadObject

                                                               i.      RuntimeDyldImpl creates an ObjectImage instance, which takes ownership of the ObjectBufferStream object

                                                             ii.      RuntimeDyldImpl loads the executable, data and common sections of the generated object, using the JITMemoryManager to allocate memory as necessary

                                                            iii.      RuntimeDyldImpl returns the ObjectImage instance to MCJIT

d.      MCJIT calls RuntimeDyld::resolveRelocations to apply relocations

3.       The client uses its JITMemoryManager to walk the loaded sections

a.       The client allocates remote memory for the section

b.      The client reapplies relocations via ExecutionEngine::mapSectionAddress

4.       The client copies the data for each section into the remote memory

5.       The client triggers remote execution

In the future, I think we might want to expose the ObjectImage directly from MCJIT.  This will be necessary to get the debug information (which isn't loaded into JMM-allocated memory) onto the remote target.

One thing I didn't mention in the above outline is that when MCJIT has applied relocations, it calls a new ObjectImage::registerWithDebugger function.  In the case of ELF objects, this will result in a call intended to hook the loaded object up with GDB.  While that will be wrong in the case of a remote target, it isn't actually new.  I just moved where the call happens.  It should be harmless, but we'll want to fix it at some point.

BTW, I'm attaching a new revision of the patch.  The only change is that I rebased it against the latest trunk code.  The old patch had become stale.

-Andy


From: Jim Grosbach [mailto:grosbach at apple.com]
Sent: Monday, September 17, 2012 9:58 AM
To: Kaylor, Andrew
Cc: Commit Messages and Patches for LLVM
Subject: Re: [llvm-commits] [PATCH] [Review request] Clean-up of MCJIT object ownership

Hi Andy,

The code looks pretty reasonable to me. At a higher level, I'm not sure I completely follow the details of the design, though. Can you explain a bit more how this works in the context of a remote target execution environment? I'm a bit concerned by some of the comments talking about readying a buffer for execution. Perhaps it's just a phrasing problem, but it's a bit of a red flag to me right now given that some commits a while back (not from you) broke remote execution very, very badly and I want to avoid a repeat occurrence. The MCJIT and RuntimeDyld do not handle anything with regards to execution of the generated code. Anything in there now that implies otherwise is a layering violation and should be removed. Perhaps you could walk me through an example of a remote process compilation and how the buffer ownership works in that context?

-Jim


On Aug 16, 2012, at 1:44 PM, "Kaylor, Andrew" <andrew.kaylor at intel.com<mailto:andrew.kaylor at intel.com>> wrote:


Hi everyone,

The attached patch implements changes to clean-up the ownership of various memory buffers and related wrapping objects in the MCJIT execution engine.

In the current implementation, the buffer into which code is generated is owned by the MCJIT component, but when sections from the generated code are loaded, they are loaded into memory owned by the JITMemoryManager.  During object loading, an ObjectFile is created within the RuntimeDyld which references both of these buffers.  The situation is further compilicated in the case where the RuntimeDyldELF object attempts to register the generated object with GDB, because the GDB-interface requires a reference to both memory buffers.  The GDB_required references are currently maintained in an ObjectImage instance which is held by RuntimeDyldELF.
I am changing this by introducing an ObjectBuffer which would be allocated by the MCJIT object at compilation time and then passed to the RuntimeDyld::loadObject.  RuntimeDyld::loadObject would hand this ObjectBuffer off to the new ObjectImage instance (which it already creates today).  The ObjectImage would be returned from the RuntimeDyld::loadObject to MCJIT and MCJIT would own that object.   The JIT memory manager continues to own the memory it allocated, but I believe the cross-dependencies are less fragile in the new implementation.

This change should also be another step toward eventual (but not yet extant) multiple module support in MCJIT.

Thanks in advance for review comments.

-Andy
<object-ownership.patch>_______________________________________________
llvm-commits mailing list
llvm-commits at cs.uiuc.edu<mailto:llvm-commits at cs.uiuc.edu>
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120917/9d0d2ec1/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: object-ownership-updated.patch
Type: application/octet-stream
Size: 31214 bytes
Desc: object-ownership-updated.patch
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120917/9d0d2ec1/attachment.obj>