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

Mon Jul 10 22:41:06 CDT 2017

Hi,

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:

1. Runtime code optimization. Java JIT does this pretty much well. But how
can a Swift code already optimized compile time benefit from it?
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.
3. Code injection. Java already enjoys this for like AOP, runtime
dependency injection, code instrumentation, etc.

Regards,

Gábor

Younes Manton via swift-evolution <swift-evolution at swift.org> ezt írta
(időpont: 2017. júl. 11., K, 0:02):

> 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
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170711/6fde36cd/attachment.html>