[swift-evolution] JIT compilation for server-side Swift

[Younes Manton]

On Mon, Jul 10, 2017 at 1:53 PM, Michael Ilseman <milseman at apple.com> wrote:

>
> On Jul 10, 2017, at 9:40 AM, Younes Manton via swift-evolution <
> swift-evolution at swift.org> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170710/eff19ef1/attachment.html>