On 01/14/2015 02:33 PM, David Blaikie wrote:> > > On Wed, Jan 14, 2015 at 2:22 PM, Lang Hames <lhames at gmail.com > <mailto:lhames at gmail.com>> wrote: > > 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. :) > > > Not necessarily - it doesn't seem unreasonable to make a plan to > ensure we don't end up with duplicate functionality to debug/test/fix > indefinitely before adding the duplicate. Seems to be common in the > project to make replacements, introduce them as an alternative but > with an explicit goal/plan from the start that this is not a perpetual > state. (for example, Chandler's pass manager work and I think most of > the bits that Chandler's rewritten (shuffling, inlining, etc) were > this way - maybe there are counterexamples where similar/duplicate > functionality was introduced without such a goal, but none come to my > mind) > > But I dunno, maybe other people find that to be an OK state of > affairs, I'm not a code owner/authority in much/any of this.As a user of the JIT, I am *very* strongly in favour of Lang's espoused position. p.s. I don't think we know what the "right" interface is for the JIT yet. Until we do, having multiple interfaces (with a single shared implementation, based on the rest of LLVM) seems entirely reasonable and appropriate. p.p.s. If Lang was proposing the replacement of MCJIT - he's not! - the review barrier would be far far higher. He'd have to satisfy all existing - well, all vocal - users of the old interface that his new one met their needs. This would be a much slower process and we want to let things evolve more quickly than that. We *don't* want to be looking at an old-JIT retirement v2. That took literally years and blocked a lot of useful work on the JIT infrastructure.> > - David > > 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/8e41c052/attachment.html>
On Wed, Jan 14, 2015 at 2:46 PM, Philip Reames <listmail at philipreames.com> wrote:> > On 01/14/2015 02:33 PM, David Blaikie wrote: > > > > On Wed, Jan 14, 2015 at 2:22 PM, Lang Hames <lhames at gmail.com> wrote: > >> 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. :) >> > > Not necessarily - it doesn't seem unreasonable to make a plan to ensure we > don't end up with duplicate functionality to debug/test/fix indefinitely > before adding the duplicate. Seems to be common in the project to make > replacements, introduce them as an alternative but with an explicit > goal/plan from the start that this is not a perpetual state. (for example, > Chandler's pass manager work and I think most of the bits that Chandler's > rewritten (shuffling, inlining, etc) were this way - maybe there are > counterexamples where similar/duplicate functionality was introduced > without such a goal, but none come to my mind) > > But I dunno, maybe other people find that to be an OK state of affairs, > I'm not a code owner/authority in much/any of this. > > As a user of the JIT, I am *very* strongly in favour of Lang's espoused > position. > > p.s. I don't think we know what the "right" interface is for the JIT yet. > Until we do, having multiple interfaces (with a single shared > implementation, based on the rest of LLVM) seems entirely reasonable and > appropriate. > > p.p.s. If Lang was proposing the replacement of MCJIT - he's not! - the > review barrier would be far far higher. He'd have to satisfy all existing > - well, all vocal - users of the old interface that his new one met their > needs. >Not necessarily - It could simply be the stated plan (& he has stated it) to reach feature parity. At that point it seems it'd be hard to justify keeping both around when one has a superset of features of the other.> This would be a much slower process and we want to let things evolve > more quickly than that. We *don't* want to be looking at an old-JIT > retirement v2. That took literally years and blocked a lot of useful work > on the JIT infrastructure. >Not sure I follow quite why the old JIT retirement was a blocker, but introducing a new JIT API with the intention to maintain both would block less work. Could you describe this in more detail? - David> > > - David > > >> 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/38599fa4/attachment.html>
> p.s. I don't think we know what the "right" interface is for the JIT yet.Orc was actually motivated in part by this. Having compassable components makes it much easier for clients to experiment with different JIT API designs, as well as new features. Hopefully any helpful lessons learned can be fed back into the tree. Again - keeping the existing MCJIT API is a fundamental requirement for the foreseeable future*. - Lang. * The caveat, which I mentioned in a previous message, is that I'm happy to discuss replacing the *implementation* of MCJIT with MCJITReplacement if/when clients are satisfied that the latter provides full feature and performance parity and compatible behavior. Such a discussion is premature though. On Wed, Jan 14, 2015 at 2:46 PM, Philip Reames <listmail at philipreames.com> wrote:> > On 01/14/2015 02:33 PM, David Blaikie wrote: > > > > On Wed, Jan 14, 2015 at 2:22 PM, Lang Hames <lhames at gmail.com> wrote: > >> 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. :) >> > > Not necessarily - it doesn't seem unreasonable to make a plan to ensure we > don't end up with duplicate functionality to debug/test/fix indefinitely > before adding the duplicate. Seems to be common in the project to make > replacements, introduce them as an alternative but with an explicit > goal/plan from the start that this is not a perpetual state. (for example, > Chandler's pass manager work and I think most of the bits that Chandler's > rewritten (shuffling, inlining, etc) were this way - maybe there are > counterexamples where similar/duplicate functionality was introduced > without such a goal, but none come to my mind) > > But I dunno, maybe other people find that to be an OK state of affairs, > I'm not a code owner/authority in much/any of this. > > As a user of the JIT, I am *very* strongly in favour of Lang's espoused > position. > > p.s. I don't think we know what the "right" interface is for the JIT yet. > Until we do, having multiple interfaces (with a single shared > implementation, based on the rest of LLVM) seems entirely reasonable and > appropriate. > > p.p.s. If Lang was proposing the replacement of MCJIT - he's not! - the > review barrier would be far far higher. He'd have to satisfy all existing > - well, all vocal - users of the old interface that his new one met their > needs. This would be a much slower process and we want to let things > evolve more quickly than that. We *don't* want to be looking at an old-JIT > retirement v2. That took literally years and blocked a lot of useful work > on the JIT infrastructure. > > > - David > > >> 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/e5cfb16e/attachment.html>
Hi Dave, Not necessarily - It could simply be the stated plan (& he has stated it)> to reach feature parity. At that point it seems it'd be hard to justify > keeping both around when one has a superset of features of the other. > >It's worth noting the distinction between API/feature replacement (e.g. the removal of the old JIT, which was seriously disruptive) and replacement of MCJIT's implementation, which should be a no-op. I have thought far enough ahead to imagine replacing the implementation of MCJIT with MCJITReplacement. I just wanted to emphatically re-assure people that I'm not going to break anything by replacing MCJIT's implementation hastily, or without consultation. As for API changes though, I can't imagine LLVM without the MCJIT API any time in the near future. There are big clients who are happy with this API. It has some warts, mostly to do with it deriving from ExecutionEngine, but it basically makes sense given MCJIT's purpose. If, in the distant future, all clients have moved onto some new Orc-based API then we could consider discarding the MCJIT API, but it wouldn't buy us much if the implementation has already been moved over to MCJITReplacement. Any new Orc-based API that supports laziness is likely use a superset of the components required to compose MCJITReplacement, so the only thing you'd save yourself is a page or two of glue code. I'd be inclined to defer any further discussion of MCJIT succession for now. We'll definitely follow best practices: We won't leave two redundant JITs in tree, but we also won't consider removing MCJIT until it is actually redundant, and that's not on the horizon. - Lang. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150114/23d09eab/attachment.html>
On 01/14/2015 02:56 PM, David Blaikie wrote:> > > On Wed, Jan 14, 2015 at 2:46 PM, Philip Reames > <listmail at philipreames.com <mailto:listmail at philipreames.com>> wrote: > > > On 01/14/2015 02:33 PM, David Blaikie wrote: >> >> >> On Wed, Jan 14, 2015 at 2:22 PM, Lang Hames <lhames at gmail.com >> <mailto:lhames at gmail.com>> wrote: >> >> 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. :) >> >> >> Not necessarily - it doesn't seem unreasonable to make a plan to >> ensure we don't end up with duplicate functionality to >> debug/test/fix indefinitely before adding the duplicate. Seems to >> be common in the project to make replacements, introduce them as >> an alternative but with an explicit goal/plan from the start that >> this is not a perpetual state. (for example, Chandler's pass >> manager work and I think most of the bits that Chandler's >> rewritten (shuffling, inlining, etc) were this way - maybe there >> are counterexamples where similar/duplicate functionality was >> introduced without such a goal, but none come to my mind) >> >> But I dunno, maybe other people find that to be an OK state of >> affairs, I'm not a code owner/authority in much/any of this. > As a user of the JIT, I am *very* strongly in favour of Lang's > espoused position. > > p.s. I don't think we know what the "right" interface is for the > JIT yet. Until we do, having multiple interfaces (with a single > shared implementation, based on the rest of LLVM) seems entirely > reasonable and appropriate. > > p.p.s. If Lang was proposing the replacement of MCJIT - he's not! > - the review barrier would be far far higher. He'd have to satisfy > all existing - well, all vocal - users of the old interface that > his new one met their needs. > > > Not necessarily - It could simply be the stated plan (& he has stated > it) to reach feature parity. At that point it seems it'd be hard to > justify keeping both around when one has a superset of features of the > other. > > This would be a much slower process and we want to let things > evolve more quickly than that. We *don't* want to be looking at > an old-JIT retirement v2. That took literally years and blocked a > lot of useful work on the JIT infrastructure. > > > Not sure I follow quite why the old JIT retirement was a blocker, but > introducing a new JIT API with the intention to maintain both would > block less work. Could you describe this in more detail?I think Lang's response covered all the relevant points and we're far off topic at this point. Let me know if there was something you think Lang's comments didn't address that you'd like me to.> > - David > > >> >> - David >> >> 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/2fc9e2df/attachment.html>