<div dir="ltr">Hi Philip,<div><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
    In terms of the overall idea, I like what your proposing.  However,
    I want to be very clear: you are not planning on removing any
    functionality from the existing (fairly low level) MCJIT interface
    right?</div></blockquote><div><br></div><div>To confirm - I have no plans to remove MCJIT. I don't want to change any behavior for existing clients. The new stuff is opt-in.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">  We've built our own infrastructure around that and require a
    few features it doesn't sounds like you're planning on supporting in
    the new abstractions.  (The biggest one is that we "install" code
    into a different location from where it was compiled.)  <br></div></blockquote><div><br></div><div>Can you clarify what you mean by "install" here? As it stands in the patch, Orc already supports cross-target and out-of-process JITing. The ObjectLinkingLayer exposes the mapSectionAddress call for mapping sections to new locations, and the MCJITReplacement demo passes all remote-jitting regression tests on Darwin.</div><div><br></div><div>The intent is that Orc should eventually provide a superset of the functionality provided by MCJIT, but with the various features broken out into separate components. I'd be interested to hear about anything that's missing so that I can, if possible, add support for it.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
    I really like the idea of having a low level JIT interface for
    advanced users and an easy starting point for folks getting
    started.  </div></blockquote><div><br></div><div>Ideally I would like Orc to cover the whole spectrum. I'm hoping we can quickly advance to the point where new JIT developers would use Orc by default, rather than MCJIT, and not miss any features. I expect advanced users will want to compose their stacks directly, while beginners would take some common configuration off the shelf. Once these patches are in tree I'm planning to add a basic lazy-jitting stack for Kaleidoscope that beginners could use as a starting point.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><div><div class="h5"><blockquote type="cite">
      <div dir="ltr">
        
        <div style="font-size:13px">(3)</div>
        <div style="font-size:13px">Q. Why "addModuleSet" rather than
          "addModule"?</div>
        <div style="font-size:13px">A. Allowing multiple modules to be
          passed around together allows layers lower in the stack to
          perform interesting optimizations. E.g. direct calls between
          objects that are allocated sufficiently close in memory. To
          add a single Module you just add a single-element set.</div>
      </div>
    </blockquote></div></div>
    Please add a utility function for a single Module if you haven't
    already.  For a method based JIT use case, multiple Modules just
    aren't that useful.  <span class=""><br></span></div></blockquote><div><br></div><div>Sure. This problem should be tackled in the wrappers around the components, rather than the components themselves. See MCJITReplacement::addModule for an example. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><span class=""><blockquote type="cite"><div dir="ltr"><div style="font-size:13px">
        </div>
        <div style="font-size:13px">(4)</div>
        <div style="font-size:13px">Q. What happened to "finalize"?</div>
        <div style="font-size:13px">A. In the Orc APIs, getSymbolAddress
          automatically finalizes as necessary before returning
          addresses to the client. When you get an address back from
          getSymbolAddress, that address is ready to call.</div>
      </div>
    </blockquote></span>
    As long as this is true for the high level API and *not* the low
    level one (as is true today), this seems fine.  I don't really like
    the finalize mechanism we have, but we do need a mechanism to get at
    the code before relocations have been applied.  <br></div></blockquote><div><br></div><div>You should still be able to intercept events to access memory before finalization. If you can be more specific about your use-case I'd be keen to figure out if/how it could be supported in Orc.</div><div><br></div><div>- Lang.</div></div></div></div></div>