<div dir="ltr">Hi,<div><br></div><div>First of all let me welcome the project. My knowledge to JITs is little but I come from Java world where JITs takes a major role. Let me share my initial thoughts on this:</div><div><br></div><div>1. Runtime code optimization. Java JIT does this pretty much well. But how can a Swift code already optimized compile time benefit from it? </div><div>2. Hot code swap. This is an interesting area. This feature would enable developers rapid development by seeing their changes as soon as the server JIT replaces modified code blocks.</div><div>3. Code injection. Java already enjoys this for like AOP, runtime dependency injection, code instrumentation, etc.</div><div><br></div><div>Regards,</div><div><br></div><div>Gábor</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">Younes Manton via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> ezt írta (időpont: 2017. júl. 11., K, 0:02):<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">On Mon, Jul 10, 2017 at 1:53 PM, Michael Ilseman <span dir="ltr"><<a href="mailto:milseman@apple.com" target="_blank">milseman@apple.com</a>></span> wrote:<br></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><span class="m_-4973133159355433780gmail-"><blockquote type="cite"><div>On Jul 10, 2017, at 9:40 AM, Younes Manton via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><div><div dir="ltr"><div><br></div><div>Having said that, it is with the static side in mind that I'm writing this email. Despite the prototype JIT being built on OMR, the changes to the static side outlined above are largely compiler agnostic APIs/ABIs that anyone can use to build similar hybrid JITs or other runtime tools that make sense for the server space.</div></div></div></blockquote></span></div></div></blockquote></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div>Do you have example APIs to discuss in more detail?</div></div></div></blockquote></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div></div></div></blockquote><div><br></div><div>Yes, I've prepared patches for the 3 items I discussed in my initial email. I've rebased onto swift/master patches that we think are a decent starting point: a high level -enable-jit-support frontend option [1] and patchable function support.[2]</div><div><br></div><div>Another patch (still based on Swift 3.0 because it needs to be implemented differently for master) for inserting in main() a call to an stdlib routine that will attempt to dlopen() an external "runtime" library, e.g. a JIT, is on another branch.[3] If ported to master as-is it would probably emit an apply to the stdlib routine at beginning of main() before argc/argv are captured. Having said that there are other ways to inject yourself into a process (I've been looking into LD_PRELOAD/exec(), for example, which wouldn't require changes to swiftc) so alternatives are welcome for discussion.</div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><span class="m_-4973133159355433780gmail-"><div></div></span><div>I think that there’s a lot of potential gains for runtime optimization of Swift programs, but the vast majority of benefits will likely fall out from:</div><div><br></div><div>1. Smashing resilience barriers at runtime.</div><div>2. Specializing frequently executed generic code, enabling subsequent inlining and further optimization.</div><div><br></div><div>These involve deep knowledge of Swift-specific semantics. They are probably better handled by running Swift’s own optimizer at runtime rather than teaching OMR or some other system about Swift. This is because Swift’s SIL representation is constantly evolving, and the optimizations already in the compiler are always up to date. I’m curious, what benefits of OMR are you hoping to gain, and how does that weigh against the complexity of making the two systems interact?</div></div></div></blockquote></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"></div><br></div><div class="gmail_extra">Yes, #1 and #2 are prime candidates.</div><div class="gmail_extra"><br></div><div class="gmail_extra">We're not so interested in retreading the same ground as the SIL optimizer if we can help it; ideally we would consume optimized SIL and be able to further optimize it without overlapping significantly with the SIL optimizer, but I think some level overlap and a non-trivial coupling with the SIL representation will be likely unfortunately.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Having access to and being able to re-run the SIL optimizer at runtime, perhaps after feeding it runtime information and new constraints and thereby enabling opportunities that weren't available at build time is a naturally interesting idea. I haven't actually looked at that part of the Swift code base in detail, but I imagine it's not really in the form of an easily consumable library for an out-of-tree code base; our prototype re-used the SIL deserializer at runtime and that was painful and hacky so I imagine a similar experience with the SIL optimizer as it currently is.</div><div class="gmail_extra"><br></div><div class="gmail_extra">The benefits of the OMR compiler is that it is a JIT compiler first and foremost and has evolved over the years for that role. More practically, it's a code base we're much more familiar with so our knowledge currently goes a lot farther and it was a quicker path to prototyping something in a reasonable amount of time. The learning curve for Swift the language + swiftc & std libs + SIL was already a significant in and of itself. Having said that I fully recognize that there are obvious and natural reasons to consider a SIL optimizer + LLVM JIT in place of what we've been hacking away on. I don't think we're at a point where we can answer your last question, it might end up that a SIL-consuming out-of-tree compiler based on a different IL will have a hard time keeping up with Swift internals and will therefore not be able to do the sorts of things we think a JIT would excel at, but we're open to a little exploration to see how well it works out. At the very least the changes to the static side of the equation are/will be useful to any other hybrid JIT or whatever other runtime tools people can envision, so from the Swift community's perspective I hope there will at least be some benefits.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Thanks for taking the time.</div><div class="gmail_extra"><br></div><div class="gmail_extra">[1] <a href="https://github.com/ymanton/swift/commit/8f5f53c7398ba9bc38dd55c60871cfe3ded68d73" target="_blank">https://github.com/ymanton/swift/commit/8f5f53c7398ba9bc38dd55c60871cfe3ded68d73</a></div><div class="gmail_extra">[2] <a href="https://github.com/ymanton/swift/commit/54e7736788f716f1c896f9b0ad56b13bcd8eb136" target="_blank">https://github.com/ymanton/swift/commit/54e7736788f716f1c896f9b0ad56b13bcd8eb136</a></div><div class="gmail_extra">[3] <a href="https://github.com/ymanton/swift/commit/f59a232e176bd050373be00228437092706cc092" target="_blank">https://github.com/ymanton/swift/commit/f59a232e176bd050373be00228437092706cc092</a></div></div>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div>