[llvm-commits] [PATCH for REVIEW] Streamline the MM for MCJIT and RuntimeDyld.

[Thirumurthi, Ashok]

Currently, RuntimeDyld clients have to specify a different memory manager from MCJIT clients.  In one case, we are compiling and loading.  In the other case, we are caching and loading.  So, clients can benefit from using the same MM for both cases.  On the other hand, clients may want a local or a remote load.  Ideally, this can be solved with two different memory managers rather than four.

Looking at the lists, I see that RTDyldMemoryManager was introduced to keep RuntimeDyld independent of the JIT engine in early days of MCJIT development.  However, the attached patch proposes reducing this dependence to a logical one by having the JITMemoryManager inherit from RTDyldMemoryManager.  Of course, it's reasonable for MCJIT to depend on RuntimeDyld and its MM because it uses both.

This approach has the advantage of illustrating which parts of the JITMemoryManager interface are relevant for RuntimeDyld clients.  It can also make it easier to deprecate the JITMemoryManager along with the JIT engine in the future.  This patch also simplifies the picture for readers of the code base by eliminating the MCJITMemoryManager class that was used to achieve the former independence between JIT and RuntimeDyld.  In addition, the change will not affect the current interface.

Finally, this patch sets the stage to add methods to protect sections and to handle multiple memory pools (i.e. to handle multiple Module/binary loads with a single memory manager).  Cheers,


-        Ashok Thirumurthi (Intel of Canada)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20121019/6a1d8970/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rtdyld-mm.diff
Type: application/octet-stream
Size: 9706 bytes
Desc: rtdyld-mm.diff
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20121019/6a1d8970/attachment.obj>