Spring (operating system)

Spring is a discontinued project in building an experimental microkernel-based object-oriented operating system (OS) 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 environment 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 OSes 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 and the Solaris operating system.

This capability was particularly exciting to companies like IBM, who were already supporting several different systems, and saw Mach as a way to combine these with common underlying code.

The performance was so poor that many commercial projects to port existing operating systems to Mach, notably IBM's Workplace OS, were eventually abandoned.

Spring also explored a number of specific software advances in file systems, virtual memory and IPC performance.

Primarily this includes state to maintain lists of running programs (domains) and their threads, as well as the communications links between them (doors).

Normally kernels need to be threaded in order to ensure a long-running task such as disk I/O won't tie up the system and prevent a subsequent call from being serviced in time; under Spring the kernel almost immediately hands off the vast majority of requests to the servers, so under this model it is only the servers which, in theory, need to be threaded.

Call/return semantics could only be supported via additional code in higher-level libraries based on the underlying ports mechanism, thereby adding complexity.

The system worked similarly to ports for the initial message; messages sent to a door were examined by the nucleus in order to find the target application and translate the door handle, but the nucleus then recorded small amounts of information from the caller in order to be able to return data quickly.

Unlike Mach's one-size-fits-all solution to IPC, Spring used a variety of methods to physically pass data between programs.

The other portions of the register stack were rendered invisible to the receiver using the SPARC's WIM instruction, providing some level of security.

The fast-path strongly resembles a classic procedure call within a single application, which uses register windows on the SPARC, adding some MMU work to move the context from one program to another.

It remains unclear whether or not the fast-path could be implemented on other machines, so the overall performance improvement of Spring is difficult to compare with Mach, which was typically measured on IA-32 systems.

Another key area of improvement in Spring was the implementation of the virtual memory (VM) system, also part of the kernel.

The VM system creates the illusion of more by using the hard disk as a backing store, an area of much slower memory used to offload inactive portions of RAM.

Under Mach the decision of where to place the VM system is not so obvious—although the kernel is in control of RAM and the MMU, the disk handlers are part of external client programs.

Unfortunately this proved to be a serious performance issue, requiring several trips in and out of the kernel (with resulting context switches along with it) as the various layers of the VM system called each other.

The result was a much more cleanly separated system of address spaces in programs, mapped by the VM into various memory objects, which were in turn managed by a pager for backing store handling.

The same kind of name/identifier dichotomy occurs in many other parts of the typical Unix system; printers are named in the etc/printcap file, small numbers and strings in the environment variables, and network locations in DNS.

Due to the fact they relied on knowing about the underlying system layout they tended to be rather inflexible, not making it easy for new services to be added.

This proved to be a serious problem, because programs had to know in advance what servers they had to call in order to ask the kernel to provide a port.

All of these could be accessed using a single API, although the system also provided a variety of stub libraries to make it appear as classical services as well, notably in the Unix emulation server.

Since doors, the real accessors in Spring, were handed out by the name service, the server included a complete access control list-based permission checking system.

In order to improve performance, the system included the concept of trust, allowing nameservers to assume requests from other servers were valid.

As mentioned before, this means that under Spring a file only exists in RAM in one place, no matter how it is being shared by the programs in the system.

The CFS also cached names from the remote system, making the initial directory traversal and open requests much faster.

However this method of compatibility was neither invisible nor guaranteed to work; Spring documents note that "many" applications will run unmodified (presumably other than relinking), but fail to mention what sort of problem areas the developer should expect if they do not.

Although not directly related to Spring per se, the Sun engineers working on the project found that existing mechanisms for supporting different flavors of calls were not well defined.