The Spring System (and its trusty sidekick, Subcontract)

1. The Spring System(and its trusty sidekick, Subcontract) Sun Microsystems

2. What is Spring? • An OS re-engineering effort from Sun • Major pieces of Solaris 2.0 came from Spring • Emphasis on interfaces between modules • Strongly typed, well defined interfaces • What rather than How • Microkernel – Spring “nucleus” • Most services implemented in user space

3. Why? • Research -> practice -> products • An effort focused on evolutionary technology • Combines several hot topics • RPC • “pattern” object design • Microkernel • Distributed objects

4. Interface Definition Language • “language-agnostic” • Interfaces not tied to a specific language • Pushes compatibility/interoperability issues “higher” • Easier to resolve (?) • IDL compiler for BPL • Client/server stub generators • Treat distributed/local objects the same

5. Object-based • “Spring” objects reside on servers • All system services advertised through IDL • Interface/implementation separation • Clients invoke through RPC (through stubs) • Client-side objects also possible • … but they still use IDL-based interfaces to communicate

6. How do objects communicate? • Very carefully! • Flexibility is the goal • One size does not fit all • Different objects, different definitions of “efficiency” • Different definitions of“communication”, in some cases • How to promote flexibility?

7. Subcontract • Replaceable layer in RPC stack • Define new ones or reuse existing ones • Sits directly on top of network code • Gives developers a set of holes to tweak behavior • If the IDL is a “contract”… • A subcontract is an interface (just like everything else!)

8. Object Internals • Spring objects have 3 components • Method table • Operations defined by IDL • Subcontract operations vector (SOV) • Local private state (“representation”) • IDL-generated code calls either methods in the method table or in the SOV • Depending on whether the call is remote

9. Client subcontract interface • Marshal – send to another address space • Local state is deleted • Unmarshal – receive from another address space • Stub code must construct new object, so peek at incoming type and use defaults • Initial subcontract builds local state from communications buffer

10. Client subcontract interface • Invoke – execute an object call • After marshalling has been done • Invoke_preamble • Gives client subcontract input into marshalling process • Marshal_copy • Optimized call where local state is not deleted

11. Server subcontract interface • Object creation – turn language objects into Spring objects • Create client object and communication endpoint • Revoke object – shut down object services • Done by closing communication endpoints • Process incoming calls – forward to server stubs

12. OK, so what’s the point? • The point is that subcontract provides an interface • If you want to do something different, you can install a new subcontract

13. Extensibility • Subcontracts can be discovered/installed at runtime • Address-space-specific registry tracks installed ones • New ones can be loaded from DSOs • Seamlessly add functionality to old programs

14. Backward/forward compatibility • Subcontracts have identifiers and a type system • Compatible types exist • So catch-all subcontracts can be installed to deal with existing applications

15. Stubs and subcontracts • Remember, the subcontract sits below the stubs • On the client side, object operations (defined by the IDL) call the subcontract operations to actually get work done • On the server side, the subcontract up-calls into the server stubs • Meta-operations needed by IDL-defined operations (copy/delete) also use subcontracts

16. Stubs and subcontracts • Subcontracts make writing the IDL stub generator easier • No need for changes for different objects, only the subcontracts change • In turn, supporting different languages becomes easier

17. The nucleus – Spring’s microkernel • Recall Liedtke – what does a microkernel need? • Address spaces, IPC, naming • Spring hits these three exactly • A Domain is an address space • A Thread is the basic computation abstraction • Doors provide calls between Domains

18. Doors • Domains have door identifiers • Mapping through door tables • Cross-domain calls implemented by thread switching • A door is basically a domain ID and a PC • Door identifiers convert to network handles for network transmission • Essentially adds network address to door ID

19. Doors and security • Door handles form basis for address-space security • They make a weak claim for unforgeability of object references, and call them software capabilities • Transitive access rights allowed – you can give away your capabilities

20. Virtual memory • Address space, memory, pager and cache objects are separate • Memory objects map into address spaces • Pager and cache cooperate • Pager provides data access • Cache provides coherency (i.e. invalidate pages) • VMM on each machine maintains pager-cache associations

21. File System • Defines a file object interface • Inherits from memory object (can be memory mapped) and IO (read/write access) • File server uses layered approach • Coherency layer on top of disk layer • Pager/cache paradigm used to enforce coherency

22. Naming • Uniform name service for all object types • Any object can be bound to any name • Standard hierarchical naming graph • Name contexts, name bindings • Naming entities are first-class • Can be exchanged, passed as parameters, etc • Name service used as hook for access control

23. UNIX Emulation • That’s right, we’re NOT talking about UNIX • Compatibility library (libue.so) provides stubs for each UNIX call • Process server runs and coordinates UNIX processes

24. The return of subcontract • Remember, all of these services are objects • With interfaces defined by IDL • That communicate by RPC • That use subcontracts • So they’re all customizeable using the subcontract mechanism • This is the power of the Spring system