|
|
|
|
|
Spring Operating SystemSpring was an experimental microkernel-based operating system developed at Sun Microsystems in the 1990s. Using technology substantially similar to concepts developed in the Mach kernel, Spring concentrated on divorcing the kernel from its Unix roots, allowing it to be used as the basis for any operating system. Development faded out in the late 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 consists of a number of such servers, each handling a specific task. Data that would normally exist only in the kernel under a traditional system would now be passed between the servers using an interprocess communications 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 deliberately modelled on the Unix file system, assigning security to ports using the fairly inflexible user/group/world model. Additionally this system proved to be a major performance problem, although the nature of this issue didn't become clear until later. However 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. Oddly, Spring did not specifically set out to address Mach's performance issues. In retrospect the project's goals do not seem all that clear at all. Mostly Spring appears to be a buzzword compliant copy of Mach, changing the language from "servers and ports" to "objects and doors". Generally the system was arranged and run as under Mach, with a number of standard servers being used to offer services such as a file system, network support and X11. Two key additions to Spring's low-level concepts relate to the way doors are handled. One change was to implement a full ACL-based security system on the doors, instead of Mach's used of Unix-like user/group/world permissioning on its ports. The true utility of this change seems limited, there are far less servers on a system than files and the overhead of managing port security on Mach was a serious performance problem already. Another addition was the concept of subcontracts, different styles of IPC suited to different tasks. While Mach supported only the memory-mapping IPC system, Spring also offered less expensive mechanisms for moving data between threads in a domain, potentially a substantial performance improvement. Even using the "expensive" cross-server call, Spring was considerably faster than Mach. On a 486DX-50 Mach required 114 usec to make such a call, while on a SPARCstation 2 Spring required only 11 usec. 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 pages 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.
|
 |
|
| Copyright 2005-2009 OnPedia.com. All Rights Reserved |
|
|