Archive for April 2, 2014

Wednesday, April 2, 2014

Implementing Plausible Crash Recovery

Landon Fuller:

The  alternative approach, and what is used on Apple’s 64-bit platforms, is the use of so-called zero-cost exceptions. Rather than recording thread state at runtime, the compiler builds a lookup table that covers all codein an executable. This table defines how to accurately unwind a single frame from any valid instruction address, as well as providing language/runtime-specific definitions of where try/catch/finally blocks are defined, and how to handle them.


As it turns out, this is exactly the same information that debuggers, crash reporters, and evil crash recovery hacks need to perform their own stack unwinding.

Second iWork ’13 Update

Dan Miller:

Apple updated its iWork suite on all three platforms (iOS, Mac, and iCloud) yesterday, with improvements to almost every aspect of every app, from editing in Pages to creating charts in Numbers and delivering presentations in Keynote.


There’s plenty more, all of it detailed on the product pages for Pages, Numbers, and Keynote. And, if you’re counting, the new Mac versions are Pages 6.2, Numbers 3.2, Keynote 6.2; on iOS, it’s version 2.2 of all three.

Ben Waldie:

I’m pleased to say that this week, Apple has delivered again. This time, the iWork apps have received a notable set of AppleScript improvements across the board.


However, the most exciting news is that Keynote, Numbers, and Pages all introduce brand new text and iWork suites of terminology, allowing for interaction with text and common elements such as charts, images, tables, lines, placed audio files, and more.

What’s especially interesting is that these suites are consistent from app to app. In other words, since all the apps have certain features in common, the same exact AppleScript terminology is used to script those features.

The Five iOS Features Apple Is Claiming That Samsung (or Google) Stole

Ben Lovejoy:

The patents are, of course, worded in the usual dense legaleze. If you want to read them for yourself, you can find them on the US Patent and Trademark Office website in the links below. But here’s my reading of what each one is about, in plain English.


Patent 5,946,647: “System and method for performing action on a structure in computer generated data”


Patent 6,847,959: “Universal interface for retrieval of information in a computer system, a patent that Apple claims is central to universal search”


Patent 7,761,414: “Synchronous data synchronization among devices”


Patent 8,046,721: “Unlocking a device by performing gestures on an unlock image”


Patent 8,074,172: Method, system and graphical user interface for providing word recommendations

Florian Mueller:

I have had discussions on Twitter and email with Apple fans who find it hard to believe that Apple, after revolutionizing the market, can’t prevent companies like Google and Samsung from providing some of the same functionality. But Apple, like everyone else in this field of incremental innovations, is standing on the shoulders of giants. A smartphone or tablet is a mobile computer, but Apple does not own all computing technology. Apple achieved key breakthroughs for those product categories. Those breakthroughs weren’t just marketing successes. They wouldn’t have been possible without certain technical achievements that made portable touchscreen devices as usable as they are now. But Apple didn’t create all of this singlehandedly on a green field. There were other touchscreen devices before, and they came with features of the kind many people mistakenly regard as foundational Apple inventions (for example, the Neonode N1m already had slide-to-unlock, even though in a less elaborate graphical form).

Surveying Various Languages’ String-search Algorithms

Nelson Elhage:

It turns out that virtually every other language [than Java] I know of uses an optimized string-search by default, which had the upshot that simply rewriting our Scala code in Ruby(!) would actually make the code dramatically faster and pass our benchmarks! “Oops”.

But inspired by this, I decided to go do a brief survey of common language/VM string-search algorithms[…]

It looks like CFStringFindWithOptionsAndLocale() uses a Java-style slow matching algorithm rather than something like Boyer-Moore.

MCS Locks and qspinlocks

Jonathan Corbet (via Kyle Sluder):

Note that the use of an atomic swap operation on the main lock means that only CPU 2 can have a pointer to CPU 1’s mcs_spinlock structure. So there is no need for atomic operations when making changes to that structure, though some careful programming is still needed to make sure that changes are visible to CPU 1 at the right times.

Once this assignment is done, CPU 2 will spin on the locked value in its ownmcs_spinlock structure rather than the value in the main lock. Its spinning will thus be entirely CPU-local, not touching the main lock at all. This process can go on indefinitely as contention for the lock increases, with each CPU placing itself in line behind those that are already there, and each CPU spinning on its own copy of the lock. The pointer in the “main” lock, thus, always indicates the tail of the queue of waiting CPUs.


An MCS lock, thus, is somewhat more complicated than a regular spinlock. But that added complexity removes much of the cache-line bouncing from the contended case; it also is entirely fair, passing the lock to each CPU in the order that the CPUs arrived.

Banned for Life

Path Finder developer Steve Gehrman:

Tried to become a professional Android developer. Didn’t realize posting some apps for beta testing would result in being banned for life by Google before even having a chance to get started. I assumed a human would be involved in any banning process and they would clearly see that I was not intending to fool anyone and that my apps were harmless. Consider this before investing time and money into developing for Android. If one of their algorithms thinks you’re a bad guy, you’re banned for life.