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

[Jim Grosbach]

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> 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
> 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/e0b34ead/attachment.html>