Hi Philip, 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? >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.> 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.) >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. 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.> I really like the idea of having a low level JIT interface for advanced > users and an easy starting point for folks getting started. >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. (3)> Q. Why "addModuleSet" rather than "addModule"? > 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. > > 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. >Sure. This problem should be tackled in the wrappers around the components, rather than the components themselves. See MCJITReplacement::addModule for an example.> (4) > Q. What happened to "finalize"? > 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. > > 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. >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. - Lang. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150114/bdb366a1/attachment.html>
On 01/14/2015 11:49 AM, Lang Hames wrote:> > 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.) > > > 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.I don't have the code in front of my right now, but I'll take a look later today and try to summarize clearly.> > 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. > > I really like the idea of having a low level JIT interface for > advanced users and an easy starting point for folks getting started. > > > 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. > >> (4) >> Q. What happened to "finalize"? >> 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. > 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. > > > 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. > > - Lang.-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150114/7f0c7727/attachment.html>
On Wed, Jan 14, 2015 at 11:49 AM, Lang Hames <lhames at gmail.com> wrote:> Hi Philip, > > 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? >> > > 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. >Why not? We did work to remove the legacy JIT in favor of MCJIT for the usual reasons (less code/maintenance burden/etc) - it'd seem unfortunate to then go back to maintaining two JITs again. You mention the intent to provide a superset of MCJIT's behavior, at which point it seems it'd be preferable to kill of MCJIT in favor of ORC (heck, we killed of the legacy JIT before MCJIT had feature parity).> > >> 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.) >> > > 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. > > 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. > > >> I really like the idea of having a low level JIT interface for advanced >> users and an easy starting point for folks getting started. >> > > 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. > > (3) >> Q. Why "addModuleSet" rather than "addModule"? >> 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. >> >> 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. >> > > Sure. This problem should be tackled in the wrappers around the > components, rather than the components themselves. See > MCJITReplacement::addModule for an example. > > >> (4) >> Q. What happened to "finalize"? >> 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. >> >> 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. >> > > 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. > > - Lang. > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150114/244279ac/attachment.html>
Hi Dave, 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. >> > > Why not? We did work to remove the legacy JIT in favor of MCJIT for the > usual reasons (less code/maintenance burden/etc) - it'd seem unfortunate to > then go back to maintaining two JITs again. > > You mention the intent to provide a superset of MCJIT's behavior, at which > point it seems it'd be preferable to kill of MCJIT in favor of ORC (heck, > we killed of the legacy JIT before MCJIT had feature parity). > >Not having plans at the moment doesn't preclude making plans in the future, it's just premature to think about replacing MCJIT when the "replacement" hasn't even been submitted to llvm-commits yet. :) The bar for transitioning is higher now, since MCJIT has more substantial clients than the legacy JIT had. The impetus for transitioning is also lower: The legacy JIT required a lot of custom infrastructure to be kept around. MCJIT is much more lightweight, and shares most of its foundation (RuntimeDyld) with Orc. If MCJITReplacement reaches full feature and performance parity with MCJIT (which I do actually want to see), and the transition can be done either transparently (by having ExecutionEngineBuilder return an MCJITReplacement instead of an MCJIT), or in a manual way that all clients are happy to buy into, then I'd be ok with deprecating and eventually removing MCJIT. That's a discussion for the future though. So clients should rest easy: We just went through a difficult transition from the legacy JIT, and I don't want to put you through that again any time soon. - Lang. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150114/f0676822/attachment.html>