<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 14, 2015 at 3:30 PM, Lang Hames <span dir="ltr"><<a href="mailto:lhames@gmail.com" target="_blank">lhames@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Dave,<div><br></div><div><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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.<br> </div></div></div></div></blockquote><div><br></div></span><div>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.</div><div><br></div><div>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.</div></div></div></div></div></blockquote><div><br>OK - that sounds great/reasonable/etc.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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.  <br></div><div><br></div><div>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. </div></div></div></div></blockquote><div><br>Yeah - providing a convenience utility based on ORC for some common (even just historic) use case, hopefully it's cheap enough (& if it isn't, we can improve ORC until it is /really/ easy to write that wrapper & comes as close to zero cost to keep as possible) that there's no cost to keeping it around.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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.</div><div><br></div><div>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.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>- Lang.</div></font></span></div></div></div>
</blockquote></div><br></div></div>