Filip Pizlo:
This post describes a new advancement in JavaScript optimization: the WebKit project has unified its existing JavaScript compilation infrastructure with the state-of-the-art LLVM optimizer. This will allow JavaScript programs to leverage sophisticated optimizations that were previously only available to native applications written in languages like C++ or Objective-C.
[…]
As we worked to improve WebKit’s optimizing compiler, we found that we were increasingly duplicating logic that would already be found in traditional ahead-of-time (AOT) compilers. Rather than continue replicating decades of compiler know-how, we instead investigated unifying WebKit’s compiler infrastructure with LLVM – an existing low-level compiler infrastructure. As of r167958, this project is no longer an investigation. I’m happy to report that our LLVM-based just-in-time (JIT) compiler, dubbed the FTL – short for Fourth Tier LLVM – has been enabled by default on the Mac and iOS ports.
[…]
The WebKit FTL JIT is the first major project to use the LLVM JIT infrastructure for profile-directed compilation of a dynamic language. To make this work, we needed to make some big changes – in WebKit and LLVM. LLVM needs significantly more time to compile code compared to our existing JITs. WebKit uses a sophisticated generational garbage collector, but LLVM does not support intrusive GC algorithms. Profile-driven compilation implies that we might invoke an optimizing compiler while the function is running and we may want to transfer the function’s execution into optimized code in the middle of a loop; to our knowledge the FTL is the first compiler to do on-stack-replacement for hot-loop transfer into LLVM-compiled code.
Unfortunately, it sounds like these optimizations—like those in Nitro—will not be available to third-party iOS apps.
Update (2014-07-17): Andrew Trick:
FTL makes it clear that LLVM can be used to accelerate a dynamically type checked languages in a competitive production environment. This in itself is a tremendous success story and shows the advantage of the highly modular and flexible design of LLVM. It is the first time that the LLVM infrastructure has supported self-modifying code, and the first time profile guided information has been used inside the LLVM JIT. Even though this project pioneered new territory for LLVM, it was in no way an academic exercise. To be successful, FTL must perform at least as well as non-FTL JavaScript engines in use today across a range of workloads without compromising reliability. This post describes the technical aspects of that accomplishment that relate to LLVM and future opportunities for LLVM to improve JIT compilation and the LLVM infrastructure overall.
Code in App Store iOS JavaScript Just-In-Time Compilation (JIT) LLVM Mac Optimization WebKit
Here’s the video and paper (via Matthew Guay):
We present Cider, an operating system compatibility architecture that can run applications built for different mobile ecosystems, iOS or Android, together on the same smartphone or tablet. Cider enhances the domestic operating system, Android, of a device with kernel-managed, per-thread personas to mimic the application binary interface of a foreign operating system, iOS, enabling it to run unmodified foreign binaries. This is accomplished using a novel combination of binary compatibility techniques including two new mechanisms: compile-time code adaptation, and diplomatic functions. Compile-time code adaptation enables existing unmodified foreign source code to be reused in the domestic kernel, reducing implementation effort required to support multiple binary interfaces for executing domestic and foreign applications. Diplomatic functions leverage per-thread personas, and allow foreign applications to use domestic libraries to access proprietary software and hardware interfaces. We have built a Cider prototype, and demonstrate that it imposes modest performance overhead and runs unmodified iOS and Android applications together on a Google Nexus tablet running the latest version of Android.
See also the discussion on Hacker News.
Android Cider iOS
Cabel Sasser:
Coda 2.5 is essentially complete. But, we’re still encountering sandboxing challenges. So, in the interest of finally getting Coda 2.5 out the door and in the hands of you, our very eager and patient customers, we’ve decided it’s time to move on—for now.
In short: Coda 2.5 will not be sandboxed, and therefore will not be available in the Mac App Store.
Recall that the original sandboxing deadline was in November 2011, shortly after the release of Mac OS X 10.7. Apple has yet to even document which APIs work in the sandbox, and there remain standard Cocoa ones that don’t. The elite Panic engineers have been working on this for years—with special help, workarounds, and exemptions from Apple—but it still doesn’t work. How many developer hours have been wasted on the sandboxing debacle?
iCloud requires the App Store, so that’s out. But we have great news. We never want to short-change our paying customers, so we’ve spent many months working on Panic Sync, our own super-easy, super-secure syncing solution that gives you power over your data.
It sounds as though Panic Sync was developed not just because of the App Store, but also because of problems with iCloud. I’m sure this is the right thing for Panic’s customers, just like Omni Sync Server was for Omni’s. But it’s sad that this sort of thing is needed.
Coda iCloud Mac Mac App Mac App Store Panic Panic Sync Sandboxing
Adam Pash (via David Heinemeier Hansson):
I recently switched from an iPhone to Android, and discovered shortly thereafter that my phone number was still associated with iMessage, meaning that any time someone with an iPhone tried texting me, I’d receive nothing, and they’d get a “Delivered” receipt in their Messages app as though everything were working as expected.
[…]
In the meantime, Apple has completely hijacked my text messaging and my phone number portability (portability between devices, not networks). No one can fix this but Apple because it’s a problem at the device level, which means people in my position have no recourse but to wait for Apple to figure out what the problem is. But Apple isn’t offering any public support on the issue that I’ve been able to find (and it’s worth repeating that proper support is behind a $20 paywall for most people who’ve switched devices, who would also be the most commonly affected by this problem).
Kif Leswing:
This isn’t a new problem, and Apple’s got several support pages and forum threads addressing it. Here’s one updated April 29 of this year called “Deactivating iMessage.” Of course, it says if you no longer have the device, you’ll be sent into an Apple Support labyrinth like the one Pash encountered.
I understand that Apple thinks this is a minor problem and that most iPhone customers end up being repeat customers, but it is a statistical certainty that there will be iPhone customers who want to keep their phone number and also want to switch to another platform, whether it’s Android, Windows Phone, Firefox OS, or something that hasn’t even been invented yet. The problem is only going to become more widespread.
Apple Bug iMessage iOS iPhone
