On Mon, Jul 10, 2017 at 1:53 PM, Michael Ilseman <[email protected]> wrote:
> > On Jul 10, 2017, at 9:40 AM, Younes Manton via swift-evolution < > [email protected]> wrote: > > 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. > > > Do you have example APIs to discuss in more detail? > 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] 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. > 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: > > 1. Smashing resilience barriers at runtime. > 2. Specializing frequently executed generic code, enabling subsequent > inlining and further optimization. > > 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? > Yes, #1 and #2 are prime candidates. 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. 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. 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. Thanks for taking the time. [1] https://github.com/ymanton/swift/commit/8f5f53c7398ba9bc38dd55c60871cfe3ded68d73 [2] https://github.com/ymanton/swift/commit/54e7736788f716f1c896f9b0ad56b13bcd8eb136 [3] https://github.com/ymanton/swift/commit/f59a232e176bd050373be00228437092706cc092
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
