Pardon my lack of knowledge about JIT compilation, but does this open the realm of possibilities to a client-side swift that would allow web developers to write swift code rather than javascript?
> On Jul 10, 2017, at 10:40 AM, Younes Manton via swift-evolution > <[email protected]> wrote: > > Hi, > > Last year a small group of developers from the IBM Runtimes compiler team > undertook a project to explore JIT compilation for Swift, primarily aimed at > server-side Swift. The compilation model we settled on was a hybrid approach > that combined static compilation via swiftc with dynamic compilation via a > prototype JIT compiler based on Eclipse OMR.[1] > > This prototype JIT compiler (targeting Linux specifically) functioned by > having itself loaded by a Swift process at runtime, patching Swift functions > so that they may be intercepted, recompiling them from their SIL > representations, and redirecting callers to the JIT compiled version. In > order to accomplish this we needed to make some changes to the static > compiler and the target program's build process. > > * First, we modified the compiler to emit code at the beginning of main() > that will attempt to dlopen() the JIT compiler, and if successful, call its > initialization routine. If unsuccessful the program would simply carry on > executing the rest of main(). > > * Second, we modified all Swift functions to be patchable by giving them the > "patchable-function" LLVM attribute (making the first instruction suitable to > be patched over with a short jump) and attaching 32 bytes of prefix data > (suitable to hold a long jump to a JIT hook function and some extra data) to > the function's code. This was controlled by a frontend "-enable-jit" switch. > > * Third, when building the target program we first compiled the Swift sources > to a .sib (binary SIL) file, then via ld and objcopy turned the .sib into a > .o containing a .sib data section, then compiled the sources again into an > executable, this time linking with the .o containing the binary SIL. This > embedded SIL is what was consumed at runtime by the JIT compiler in order to > recompile Swift functions on the fly. (Ideally this step would be done by the > static compiler itself (and is not unlike the embedding of LLVM bitcode in a > .llvmbc section), but that would have been a significant undertaking so for > prototyping purposes we did it at target program build time.) > > That's the brief, high level description of what we did, particularly as it > relates to the static side of this hybrid approach. The resulting prototype > JIT was able to run and fully recompile a non-trivial (but constrained) > program at comparable performance to the purely static version. For anyone > interested in more details about the project as a whole, including how the > prototype JIT functioned, the overhead it introduced, and the quality of code > it emitted, I'll point you to Mark Stoodley's recent tech talk.[2] > > 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. As such, we felt that it was a topic that was > worth discussing early and in public in order to allow any and all > potentially interested parties an opportunity to weigh in. With this email we > wanted to introduce ourselves to the wider Swift community and solicit > feedback on 1) the general idea of JIT compilation for server-side Swift, 2) > the hybrid approach in particular, and 3) the changes mentioned above and > future work in the static compiler to facilitate 1) and 2). To that end, we'd > be happy to take questions and welcome any discussion on this subject. > > (As for the prototype itself, we intend to open source it either in its > current state [based on Swift 3.0 and an early version of OMR] or in a more > up-to-date state in the very near future.) > > Thank you kindly, > Younes Manton > > [1] http://www.eclipse.org/omr/ <http://www.eclipse.org/omr/> & > https://github.com/eclipse/omr <https://github.com/eclipse/omr> > [2] http://www.ustream.tv/recorded/105013815 > <http://www.ustream.tv/recorded/105013815> (Swift JIT starts at ~28:20) > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
