<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">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?<div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jul 10, 2017, at 10:40 AM, Younes Manton via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">Hi,</div><div class=""><br class=""></div><div class="">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]</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">* 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().</div><div class=""><br class=""></div><div class="">* 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.</div><div class=""><br class=""></div><div class="">* 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.)</div><div class=""><br class=""></div><div class="">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]</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">(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.)</div><div class=""><br class=""></div><div class="">Thank you kindly,</div><div class="">Younes Manton</div><div class=""><br class=""></div><div class="">[1] <a href="http://www.eclipse.org/omr/" class="">http://www.eclipse.org/omr/</a> & <a href="https://github.com/eclipse/omr" class="">https://github.com/eclipse/omr</a></div><div class="">[2] <a href="http://www.ustream.tv/recorded/105013815" class="">http://www.ustream.tv/recorded/105013815</a> (Swift JIT starts at ~28:20)</div><div class=""><br class=""></div></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></body></html>