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

[Kaylor, Andrew]

ping

From: llvm-commits-bounces at cs.uiuc.edu [mailto:llvm-commits-bounces at cs.uiuc.edu] On Behalf Of Kaylor, Andrew
Sent: Tuesday, August 28, 2012 11:11 AM
To: Commit Messages and Patches for LLVM
Subject: Re: [llvm-commits] [PATCH] [Review request] Clean-up of MCJIT object ownership

ping

From: llvm-commits-bounces at cs.uiuc.edu<mailto:llvm-commits-bounces at cs.uiuc.edu> [mailto:llvm-commits-bounces at cs.uiuc.edu] On Behalf Of Kaylor, Andrew
Sent: Thursday, August 16, 2012 1:44 PM
To: Commit Messages and Patches for LLVM
Subject: [llvm-commits] [PATCH] [Review request] Clean-up of MCJIT object ownership

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120905/968d5533/attachment.html>