<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"><base href="x-msg://4913/"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">This all seems totally reasonable to me. Please apply.<div><br></div><div>Thanks!</div><div><br></div><div>-Jim</div><div><br><div><div>On Oct 19, 2012, at 2:16 PM, "Thirumurthi, Ashok" <<a href="mailto:ashok.thirumurthi@intel.com">ashok.thirumurthi@intel.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div lang="EN-US" link="blue" vlink="purple" style="font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div class="WordSection1" style="page: WordSection1; "><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; ">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.<o:p></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; "><o:p> </o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; ">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.<o:p></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; "><o:p> </o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; ">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.<o:p></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; "><o:p> </o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; ">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,<o:p></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; "><o:p> </o:p></div><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 11pt; font-family: Calibri, sans-serif; text-indent: -0.25in; "><span>-<span style="font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-family: 'Times New Roman'; "> <span class="Apple-converted-space"> </span></span></span>Ashok Thirumurthi (Intel of Canada)<o:p></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; "><o:p> </o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; "><o:p></o:p></div></div><span><rtdyld-mm.diff></span></div></blockquote></div><br></div></body></html>