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