cluding
doors, distributed memory management, and universal naming) will appear in future versions of Solaris. But it will never be Spring again.
Open-Door Policy
One key idea in Spring is that applications can access objects located anywhere on a network. You can use the same source (and object) code to access objects within the same process, within the same machine but in different processes, and within a network of cooperating machines (called a
village
). Spring enables this distribution by keeping interobject communication abstract: Object A may ask Object B to do something, but it can't specify
how
it gets done.
From the application writer's perspective, there is only one kind of object in Spring. From the object implementor's perspective, there are two: server-based and serverless. Server-based objects can be in any address space, including the same space as the client application that called them. If the client invokes an operation on a ser
ver-based object that is not implemented in the client's address space, the kernel may be involved with the object invocation. For a serverless object, the kernel dynamically loads a shared library that implements the object's code into the client's address space. Serverless objects are primarily a performance optimization for lightweight objects like
names
.
Spring objects run in
domains
that are like Unix processes. Spring domains have an address space, and they hold information about
threads
, and they have
doors
, entry points into other domains.
Each object contains a list of the
subcontracts
(relatives of RPC/IPC) that the object supports. Each object also contains the data the client has that the stubs and subcontract use to forward the object invocation to the proper destination, called the object's
representation
.
When a client calls a server-based object, it passes its request through a client stub. This stub
marshals
t
he arguments -- places them into a communication buffer with enough information so that the server can figure out what's going on. The stub then passes them to the subcontract which, in turn, executes the call to the server-based object. The server-based object, for its part, has a subcontract that "unmarshals" the arguments. Then a server-side stub invokes the appropriate method on the object.
At the center of interdomain communication is the Spring microkernel, called the
nucleus
. (The entire microkernel consists only of the virtual-memory manager and the nucleus; see the figure
"Door-to-Door Communication"
.) When a thread in one address space invokes a door for an object in another address space, the nucleus allocates a server thread in the second address space, then passes the server thread information about the door that the thread invoked, as well as any arguments. Then the nucleus lays low until the server is done, at which point the nucleus reactivates the thread
that called the server and passes it any return information.
So how does the nucleus keep track of what machine every object is on? The answer is simple: it doesn't. Instead, Spring has proxies -- pointers to where objects really live. So when a Spring system starts, the proxies give each other something roughly equivalent to their root directories. Later on, the naming system can use these directories (actually called
contexts
) to locate objects on other systems. The two systems talk to each other and create a secure link over which object invocations can flow.
Then, when an object on machine A wants an object on machine B, the proxy takes the object reference, compares it to its table of where the object really lives, then substitutes a local object that's basically an index -- a pointer to the remote object. If the client on machine A has no reference to the object on machine B, the client will usually use some naming operation to locate the object. The proxy on A will then automati
cally create the reference to the remote object.
Interface Definition
To ensure that objects talk to each other in consistent ways, Spring has an interface definition language (IDL) that compiles into the source-code language of your choice. The IDL is an abstract language, similar to the Object Management Group's IDL spec. Defining an object with the IDL is a matter of defining the methods you want that object to have.
Once you've written your IDL, you run it through a compiler that generates three pieces of source code: a language-specific form of the IDL interface, the client-side stub code, and the server-side stub code. The language-specific form of the IDL interface is typically a header file (for C and C++) with definitions for the methods, constants, and types you defined in the IDL. You compile client- and server-side stub code and link them into client and server programs or libraries so that objects can talk to their subcontracts.
When you study the syntax,
IDL looks like C++. Perhaps more than Jim Mitchell, Sun fellow and Spring cocreator at SunSoft, would like. "But compromise is the price of getting a technology standardized," he says. For example, an IDL interface might look like this:
import raw_data;
module io {
enum error { bad_size,
illegal_offset, full,
not_available };
exception failure { error code;
};
exception end_of_data { };
interface sequential_input {
raw_data read(in long
size) throws (failure,
end_of_data);
};
interface sequential_output {
void write(in raw_data
data) throws (failure,
end_of_data);
};
interface sequential_io:
sequential_input,
sequential_output {};
};
Mitchell explains why Spring needed its own IDL: "When we started this project, we wanted to make a system as open as possible, particularly not tying people to one programming language. We knew we needed strong interfaces. The only way to get it would have been to have a programming language wi
th strong interfaces. To get both, we had one language to describe interfaces."
I Cannot Tell a libc
SunSoft never defined Spring as Unix, no matter how far you stretch the definition of Unix. Consequently, applications written for SunSoft's current Solaris operating system won't run on Spring without emulation. The emulation system that SunSoft created acts as a kind of translator, changing an application's calls into Unix services that have Spring counterparts. When Spring has no counterpart, the emulation system performs the call itself. Consistent with Spring's microkernel architecture, the whole emulation system runs in user space -- it's not part of the kernel.
The emulation system consists of two basic parts: a shared, dynamic-linked library (called
libue.so
) and the Unix process server. Solaris binaries make calls to
libc
. Spring just replaces libc with libue by changing the search path. When you run a Unix application (or some other application exe
cutes it), Spring dynamically links libue instead of libc to it; the application doesn't change. After looking at every system call that the application makes, libue either maps it to a Spring function or, in the case of a function that has no equivalent (such as signals), implements it directly.
The Unix process server tracks processes and group IDs and provides services such as sockets and pipes. Since it has its hand on the pulse of Unix applications, the process server enforces Unix security semantics.
Memory's the First to Go
Spring's memory-management system is fairly simple. A client talks to an address-space object. The address space maps to a memory object -- e.g., a file. These two objects are the result of the cooperation of the virtual-memory manager (VMM) and an external pager.
The VMM manages the address-space objects, while the pagers manage the memory objects. The pager supplies and stores the actual contents of a memory object to the VMM. The VMM then
binds that memory object into an address space. If the memory object happens to be on a remote system, the bind operation points the VMM to a local data cache that provides the memory object's contents.
During binding, the VMM and the pager exchange two objects: the pager object and the cache object. The pager object provides methods for paging in and out memory. It uses the cache object to change the state of the cache.
So a client talks to its address-space object which, through the VMM and pager systems, manages the caching and paging of memory. Why is this approach significant? Because the memory object is separate from the pager. Since they're separate, the memory object and the pager object may be in separate domains, which can improve performance. The Spring file system, an important client of the virtual-memory system, is a good example. The file system caches all file attributes in a caching file system (CFS) on the local node. The VMM is responsible for caching the actual data. When a
client is dealing with a remote file, all reads and writes go to the CFS on the local machine, and only when Spring needs to page in or out does it have to hit the remote system.
A Rose by Any Other Name
Files get one kind of name, users get another kind of name, computers on the network get yet another. Most people who are used to computers are used to the split personality of naming services. Spring is going to be a shock: Its naming service is uniform -- it can bind any object to any name. In theory, at least.
The advantage is that the clients don't have to keep track of how to talk to different naming services depending on what kind of object they're calling, nor do they have to create naming spaces.
Spring's naming service binds names to objects. An object may have several different names, depending on the context in which it's used, or it may have no name at all. Since a context is itself an object, Spring may bind it to a name (resulting in a name that represe
nts many names). To keep track of what objects are called within this compound structure, Spring creates a naming graph. For example, you may put the file system into a naming graph, linking it to another object's name space so that object can find its way through the maze of objects to locate a specific file.
The naming service has another purpose: It provides Spring with a kind of object persistence. Most of Spring's objects aren't themselves persistent (i.e., they don't always have a place on a storage medium somewhere), but names can be. (In case you're wondering, the file system
is
persistent; otherwise, you'd be unlikely to find your files after you rebooted.) So Spring can keep an object's name around, thereby keeping information about the object. Another object can find the first object through the naming service.
Using Spring
According to several users who've worked with it, you can tell that Spring is an experiment, not a commercial operating system. SunSo
ft's efforts have revolved around architecture, leaving elements
like the user interface somewhat
bereft of attention.
Tom Doeppner, research associate professor at Brown University, cites a few of Spring's shortcomings. "We have a somewhat unusual graphics option on many of our SparcStation 10s [the ZX board] that Spring did not support," he reports. Further, some aspects of performance, notably the Unix emulation, aren't very quick. Says Doeppner: "Those portions of Spring that are new technology, such as interprocess method invocation, are very fast. The not-so-new-technology parts, in particular Unix emulation, are a bit slow. Unfortunately, when one sits down to play with Spring, the first thing one notices is the speed of the Unix emulation. Since the compilers and other tools come from Unix and are run using Unix emulation, compiles and related things go fairly slowly, though the resulting code, when it uses only native Spring features, is quite quick."
Doeppner re
alizes Spring is a prototype: "Spring is somewhat of a memory hog. SunSoft clearly put its resources into providing functionality without worrying about memory usage. However, they were kind enough to lend us a memory upgrade."
Not everyone is happy with how the IDL turned out, either. Vince Russo, assistant professor at Purdue University, explains that the problem isn't so much with Spring but with the IDL's adherence to the CORBA standard. "I have some complaints about deficiencies in the CORBA type system," he says. The biggest complaint is that "in the Spring IDL, you can't overload methods . . . The problem I have with CORBA is that you have to pre-agree about everything. I would prefer a more dynamically typed language," Russo says.
High Praise
Despite any shortcomings on this level, however, everyone we spoke to about Spring had high praise for it. "From an operating-system-internals point of view, throwing away the Unix process model and introducing really fast inter
process communication is a great technological step forward," says Darrell Long, associate professor at the University of California at Santa Cruz. Long was so enthused that he was considering working on a port of Spring to Intel-based systems but didn't have the resources to do it. He estimates that a porting project like that would take about one person-year.
Purdue's Russo echoes these sentiments. "I like the fact that the object orientation is pervasive -- Spring doesn't pay just lip service to objects. You use the same model for accessing all resources. It's a nice orthogonal way of looking at the OS."
Spring is an experiment, not a version of a forthcoming commercial operating system. According to SunSoft's Mitchell, "The plan is to pull out of it the best of the technology" and implement it in Solaris. Ultimately, SunSoft aims to extend Solaris and aid it in dealing with "weird" architectures such as a nonuniform-memory machine.
What parts of the Spring technology are going to make
their way into Solaris? Doors, for one thing.
But ultimately, Spring seems bound for the bit bucket, with only parts of it surviving in future versions of Solaris. The near-universal cry from users is that that's too bad. "If it were my call, they would post the source code to the Net," says Long. "If it were made openly available, it would certainly be ported and its technology would spread. I'm really sorry to see it just sort of going away."
PRODUCT INFOMATION
Spring.......................$75 for universities
............................$750 for commercial research institutions
(SparcStation 2, 5, 10, or 20)
SunSoft
Mountain View, CA
(415) 960-3200
spring@sun.com
http://www.sun.com
:80/tech/projects/spring/index.html
Circle 988 on Inquiry Card.
Sunsoft'S Object Lesson
