Apple's March Event

There's a rumor that an Apple event next week will introduce iPhone OS v. 3.0.

Although billed by some as "early", I believe this isn't particularly soon for such an announcement. Apple's announcement of its next desktop operating system came last summer, after all, and one of the benefits of Apple's operating system and development environment is the ability to build both from a single code base, and allow developers of either to leverage Cocoa to produce solid and efficient applications. If Snow Leopard nears, it makes sense that the next iPhone OS will also near. I suspect that the effort to make Snow Leopard a leaner, faster cat has also been part of a program to keep the architectures closer together. I view the leaned-down iPhone OS 2.0 as something like Leopard 1.5, with Snow Leopard being "Leopard 2.0" -- like the original in vision, but with refinement. For example, the kludge used in the 10.5-and-earlier kernels to enable greater-than-4GB memory addressing from a 32-bit kernel will apparently disappear as xnu goes 64-bit through-and-through. (The problems of large RAM in x86 machines with 32-bit addressing isn't a Mac problem; Apple has actually delivered a bit better on its promises to consumers than some manufacturers.)

I don't see evidence the March 17th event is actually a product release date, so I suspect it's just a feature announcement. The fact that Apple is far enough along with the new kernel that it can discuss upcoming iPhone OS versions (without MSFT-like feature attrition along the way) is a Good Thing™. The fact that Apple is announcing it in advance is perhaps designed to stoke developer interest in the face of competition for developers, and designed to excite people about the future of the platform -- including the free software updates iPhone users can expect.

I think a faster iPhone OS will be good for everyone, and I think the new tech for distributing computation demand to available processing units (I'm looking at you, graphics subsystems and DSPs and additional processors) will be as valuable on handhelds like iPod/Phone as on notebooks and desktops.

In connection with this, I believe that discussion of MacOS X acquiring ULE from FreeBSD should be dismissed. The MacOS X scheduler is not part of its BSD heritage or a historic part of Apple's synchronization of its BSD kernel with the FreeBSD kernel tree; obtaining a new scheduler from FreeBSD thus makes no sense. The objectives of recent FreeBSD updates have already been partially attained in xnu (e.g., the preemptible and re-entrant multithreaded kernel appearing only relatively recently in FreeBSD), and attaining additional benefits may be a matter of further incremental work rather than a matter of wholesale replacement of the scheduler.

The MacOS X thread scheduler is part of xnu's Mach heritage. Considering that xnu (the MacOS X kernel) implements BSD threads atop Mach threads, and that much of how MacOS X achieves its various performance miracles (e.g., copy-on-write, etc., that make some data-intensive transactions nearly free in some cases) requires maintenance of Mach primitives and their behavior, a scheduler designed for a different thread primitive seems an unlikely new feature. All the userland frameworks depend on assumptions about the behavior of Mach threads, for example. Elimination of Mach threads and their scheduler would add a kind of rippling complexity, threatening not only Apple's userland code but that of every developer that ever worked with the old Mach thread behavior.

Given the relative revolution that has occurred since the initial release of MacOS X -- the open-sourcing of the well-known, stable, mature, and widely-deployed Solaris operating system, for example, and the development of real-time performance solutions on open-source operating systems -- it's not entirely implausible that Apple might one day vigorously re-invent the internals of MacOS X. Apple has already paved the road in that direction by providing IOKit (so that many device drivers need not care about operating system internals, so long as they interface with established interfaces) and, more recently, KPIs (to free more drivers from dependence on the implementation details of the kernel such as particular versions of data structures or the like). By allowing third-party code that must run in kernel space to interface with the kernel without leaving the code subject to obsolescence every time the kernel is updated (that is, at every point release) or given a significant performance or feature upgrade (likely at a major release) -- because the third-party kernel code is now capable of using published interfaces that don't change despite radical refactoring of the kernel algorithms and the addition of new features -- Apple has been freed from the shackles of reverse-compatability limitations. Apple has given developers a path to write relatively future-proof code, and gained the power to revise dramatically the details of its kernel implementation. Thus, the day may come that Apple decides its kernel architecture has outlived its usefulness and replaces it -- without users really noticing (other than to reap the benefit).

However, it's not clear that Snow Leopard is that point. FreeBSD seems to have implemented ULE only recently, ULE appears not yet to have achieved things Apple already had obtained, and Apple has been working like a fiend on things like OpenCL and an improved multitasking architecture, all with apparent independence from the FreeBSD updates and release schedules. As an outside observer, I figure that at present, the scheduler is something at which Apple is ahead of the game, but Apple's work on making the implementation details irrelevant to developers will have the effect of leaving Apple free later to adopt superior under-the-hood solutions if and when they appear.

If Apple wanted to create a serious under-the-hood revolution, the switch to a 64-bit kernel (which necessarily requires at least a 64-bit recompile of any prior third-party in-kernel code) would not be a bad time to launch it.

Upshot:
iPhone OS v. 3.0 will be a feature announcement and not a product release, and it will reflect improvements Apple is making in Snow Leopard (while being slowed from release by those issues that would slow Snow Leopard). Improvements in iPhone -- like the ability to use the iPhone as a bluetooth wireless modem for notebooks, or simply the ability to cut and paste -- are not hard to imagine even without considering fundamental issues like better utility of various hardware (digital signal processors, graphics subsystems, multi-core general-purpose processors, etc.) and other performance issues. iPhone OS v. 3.0 will be largely an event to seduce developers, but it will also draw attention to the value Apple has acquired for its naescent platform.

The possible future of this handheld platform may feature again in future handheld rumors, but for now it's safe to say that Apple has defied critics not only to succeed in cellular phones but also to establish the dominant platform for vending third-party smartphone applications.