No, this is completely unrelated. This is about runtime optimization of already-running swift programs.
> On Jul 10, 2017, at 10:40 AM, Jacob Williams via swift-evolution > <[email protected]> wrote: > > 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] <mailto:[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] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > 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
