News: Stay up to date

The Étoilé community is an active group of developers, designers, testers and users. New work is being done every day. Visit often to find out what we've been up to.

News

The Étoilé Runtime is dead, long live the GNUstep runtime!

Posted on 10 September 2009 by David Chisnall

A few years ago, I wrote a new Objective-C runtime, which had lots of new and exciting features, but one big disadvantage; it was not backwards compatible. Since then, I've been heavily involved in clang and have implemented support there for the GNU runtime. I added preliminary support for the new runtime, but it bitrotted before I finished it.

After looking at the GNUstep code, I came to the conclusion that updating it to support a new runtime would be very difficult. In particular, changing the type of IMP would have broken a lot of existing code.

Since then, I've also been working on ObjectiveC2.framework in Étoilé svn. This provides an implementation of Apple's new runtime API on top of the GNU runtime. This makes it easier to port code from OS X to GNUstep and also implements a few of the newer functions that clang is now adding calls to for Objective-C 2 support. These include bits of the language like fast enumeration (for...in loops), @synchronize(), and declared properties.

About a week ago, I started a new project. This has now been committed to the GNUstep repository as libobjc2. The new runtime starts as a fork of the GNU runtime, incorporates the improvements from the ObjectiveC2 framework, a number of ideas from the Étoilé runtime, and a little bit of new stuff.

From the GNU runtime we get a fairly reasonable implementation of the core Objective-C language. From the ObjectiveC2 framework we get most of the things required for Objective-C 2. From the Étoilé runtime we get a safe way of caching method pointers (so the compiler can now safely insert IMP caching and you probably never need to do it in code ever again) and a means of modifying the receiver of messages (so we can now implement incredibly fast proxies for things like CoreObject). The new stuff includes built-in support for Object Planes, support for non-fragile instance variables, introspection on declared properties and optional methods in protocols, and a few other things. The performance characteristics of the GNUstep runtime are similar to those of the Étoilé runtime; slightly slower than the GNU runtime for basic message sends, faster for cached message sends, and much faster for proxy messages.

I finished the compiler support for all of the new features last night and will be committing it to clang once it's undergone code review. In the meantime, I've been updating GNUstep so that it now supports all of the new magic on NSObject added with 10.5 and 10.6. I've also added type introspection on blocks, so we can use them with ETPrototype safely, just as we use Smalltalk blocks now.

The Étoilé runtime is now official deprecated. It should be regarded as a research prototype. Almost all of the ideas from the paper have now been merged into the GNUstep runtime. The - horribly buggy, bloated, and untested - threading code has now all gone. The current version of the runtime does not support type-dependent dispatch, but it does return the method types in the slot, so they can be tested in LanguageKit to avoid problems with polymorphic selectors. One feature that was dropped was the offset field in slots. After profiling, it was determined that the test for whether this field was present on every message send was costing more than it was saving in the cases where it existed. We can get the same benefit in a more general way by speculatively inlining the accessor methods.

The new runtime is now fully supported by GNUstep, bringing support for all of the 10.5 and 10.6 methods that were added to NSObject. The patches for support in clang are pending review, but should be merged soon. Once this has been done, I will also add LLVM passes that automatically cache the lookup. This optimization code can then be shared between clang and LanguageKit, because it will work on the LLVM IR generated by either.