Spring (operating system)

Spring was an experimental microkernel-based object oriented operating system developed at Sun Microsystems in the early 1990s. Using technology substantially similar to concepts developed in the Mach kernel, Spring concentrated on providing a richer programming enviornment supporting multiple inheritance and other features. Spring was also more cleanly separated from the operating systems it would host, divorcing it from its Unix roots and even allowing several OS's to be run at the same time. Development faded out in the mid-1990s, but several ideas and some code from the project was later re-used in the Java programming language libraries.

The Spring project started in the immediate aftermath of the release of Mach 3. In earlier versions Mach was simply a modified version of existing BSD Unix kernels, but in Mach 3 the Unix services were run as a separate server as a user-space program like any other. In theory the Unix server could be replaced with another, allowing Mach to run as the basis for any modern operating system. In its ultimate development, an OS on Mach would consist of a number of such servers, each handling a specific task. Data that would normally be private in the kernel under a traditional system would now be passed between the servers and user programs using an interprocess communications (IPC) system, ending in ports that both servers held. Mach implemented these ports in the kernel, using virtual memory to move data from program to program, relying on the memory management unit (MMU) and the copy on write algorithm to do so with reasonable performance. The servers could be run on demand, allowing the user to tailor the system to their needs simply by starting or stopping programs.

In fact this was not so easy. Mach made several decisions at a low-level that made any system running on it Unix-like to some degree. Most notable was a security system that was modelled on fairly inflexible inherited model of Unix programs. Additionally the IPC system proved to be a major performance problem, although the nature of this issue didn't become clear until later. The performance was so poor that many commercial projects to port existing operating systems to Mach, notably IBM's Workplace OS and Apple Computer's Star Trek, were eventually adbandoned.

Spring concentrated on "programmibility", making the system easier to develop on. The primary addition in this respect was the use of a richer interface definition language (IDL), which exported interfaces with considerably more information than the one used in Mach. In addition to functions and their parameters, Spring's interfaces also include information about what errors can be raised and the namespace they belong to. Given a proper language, programs, including operating system servers, could import multiple interfaces and combine them as if they were objects native to that language -- notably C++, which was a major target language although Spring documentation seems to pretend this is not the case.

Note that Mach can be used in a Spring-like fashion in this regard with little effort. After exporting the Mach interface in the IDL, the code can then be wrapped in any target language to provide an object layer. This was extensively used in various Mach projects under C++, as well as on NeXTSTEP/MacOS X under Objective-C. However this does not imply the resulting system will be as easy to use. In particular the lack of a namespace mechanism means that the resulting interfaces will be a "big bag of functions" unless the developers take care to organize the resulting code. In the end it seems there is little real-world difference.

Although not part of the IDL itself, Spring also included hints, referred to as subcontracts, about how to physically make calls between programs. The most common subcontract was a singleton using Mach-like IPC to pass data from one program to another. Although buzzword compliant, singletons are really nothing more than applications being sent messages using IPC; in other words, identical to the Mach model in all but name. Spring also included other subcontracts for lightweight (in-process) objects, caching, and error handling, which seem to demonstrate the utility of the concept.

Spring also used a single access control list-based (ACL) security system for all permissioning. Unlike Mach, which followed the Unix model without seeming to have given it any thought, using ACL's in the root of the system meant that they were univerally available. For instance, implementing ACL's in the file system simply meant writing them down, the user's requests would already be checked against them as a natural part of trying to send IPC to the file system server.

Although Spring did not specifically set out to address performance issues, the system was nevertheless much faster than Mach. Specifically, Mach IPC was fairly slow, much slower than the analagous syscall or trap into a Unix kernel. Measurements showed that such a call took about 20 usec on a 486DX-50 for existing BSD Unix systems, and 114 usec under Mach. This led to a performance hit of 50% or more, and doomed most Mach projects. In retrospect the vast majority of this time is spent poorly, applying rights and permissioning and checking the message for validity. These are better handled by the applications that need them, and only those applications, whereas under Mach IPC was a serious distributed cost.

In contrast, Spring boasted a IPC time of only 11 usec on a SPARCstation 2. The exact reasons for this excellent performance are not clear, as explainatory documents are no longer easily available. It is likely that some of this is due to architechtual differences between the x86 and SPARC processors, but that could not explain it all. It is more likely that Spring removed the type checking and permissioning from the kernel itself, as was done on more modern kernels such as L4. This leaves some question to the overall effect on performance, although the functionality does not appear to belong in the kernel, it still has be run somewhere.

Spring's kernel was divided into two parts, the nucleus which provided application support, task management and IPC, and the vm manager which handled memory. Another serious performance problem under Mach was poor vm because the system didn't have a real understanding of the operating system as a whole, under Spring this was addressed by special-casing the vm. Developers could write custom pagers tuned for different workloads, and link them directly into the kernel for added performance. Mach also added user-built pagers in Mach 3, but used the IPC mechanism to communicate with them, adding a serious performance overhead.

Another key addition was a naming service for doors. Mach had developed from the Unix model, where devices were represented as "well known files"; for instance a printer could always be found in the /dev directory. Mach 2 was a re-programming of BSD and did not offer too much flexibility, so it wasn't until Mach 3 arrived that problems with this concept became clear. Under Mach 3 it was imagined that a user could start or stop servers as they wanted, which meant that the system would have no idea exactly what was running or how to serve various requests, there were no "well known" servers given that the vast majority of the operating system was unknown.

Spring added what is, in retrospect, an obvious solution, a single well-known name server that hands out door addresses on demand. Under Spring applications could discover what capabilities were available and what server was handling them. Although in most cases the ports/doors would indeed be well known -- a Unix server would know to expect certain Unix servers, a Mac OS server would know to expect certain Mac OS servers -- Spring was developed with the express intent of allowing several completely different operating systems to be run at the same time. Under this model, the name server becomes very important.