The Alta Operating System

1. The Alta Operating System Patrick Tullmann Masters Thesis Defense University of Utah

2. Alta • Alta is an operating system in aJava Virtual Machine • Manages multiple applications on a single JVM • Supports the Fluke OS nested process model (NPM)

3. Research Goals • Can I change the protection mechanism in an OS model? • Can I provide safe, controlled sharing between Java processes?

4. UT NV Uniglobe Morris Public Area Registered Agents Airline Database Motivation: Servlet Engine

5. Motivation • Java Virtual Machine provides: • Safety • Platform independence • Java-based systems need: • Multiple “user” management • Resource management • Flexible & extensible control

6. Approach • Traditional OS a good model • Hardware provides safety mechanism • OS provides management • Fluke OS nested process model

7. Fluke Background • Microkernel • Threads, mutexes, IPC, … • Manages CPU and memory • User-level services • File, Network, … • Nested process model • Structured • Well defined

8. 1 2 Child A Child B Parent Process Nested Process Model • A model of how processes interact • Hierarchical: parent process provides resources

9. Mapping an OS into Java • Type safety replaces hardware page protections • Bytecodes replace simple instructions • Native methods replace privileged instructions • All higher-level abstractions are equivalent

10. Goals for Alta • Support Fluke features for process management • Mimic Fluke structure • Provide parent process with control • Acceptable performance • Maintain backwards compatibility • Existing Java apps should work

11. Design of Alta • Four design aspects (really seven) • Maintain “whole JVM” illusion • Per-process, flexible typespaces • Inter-process sharing • Sharing & resource control • IPC-based interfaces • Exportable kernel state • Kernel implementation

12. Design of Alta • Four design aspects • Maintain “whole JVM” illusion • Per-process, flexible typespaces • Inter-process sharing • Sharing & resource control

13. Design of Alta • Four design aspects • Maintain “whole JVM” illusion • Per-process, flexible typespaces • Inter-process sharing • Sharing & resource control

14. Per-process Typespaces • Typespace: Set of name to class bindings in a process • Extension of the NPM to Java • Parent process resolves all class names • Enables access controls • Enables code control in child process • Problems with native methods • Poses problems for sharing

15. Per-process Typespaces • Implies class has no fixed name • Implies there can be inconsistencies • Different notion of ‘File’ • Same notion of ‘Directory’

16. Design of Alta • Four design aspects • Maintain “whole JVM” illusion • Per-process, flexible typespaces • Inter-process sharing • Sharing & resource control

17. Inter-process Sharing • Alta allows limited inter-process sharing • Initial sharing via IPC • Sharing through other shared objects • Processes can have inconsistent types • Inter-process type inconsistencies can destroy a JVM • pointer forging

18. Inter-process Type Checking • Alta ensures equivalent types for all shared objects • Effective limits on shareable types: • Completely consistent field types • Only allows non-polymorphic fields

19. Design of Alta • Four design aspects • Maintain “whole JVM” illusion • Per-process, flexible typespaces • Inter-process sharing • Sharing & resource control

20. Sharing & Resource Control • Sharing complicates resource control • Termination of process that has “exported” objects • Alta lets applications control sharing • Nested process model enables constrained sharing

21. User-level Shared Objects • Child allocates -> Parent references • Harmless. If parent dies then child dies • Useful. Child can pass IPC arguments • Sibling allocates -> Sibling references • Allowable. Parent trades communication costs for separation • Parent allocates -> Child references • Standard server behavior • Cannot deallocate without child’s cooperation

22. Results & Evaluation • Micro-benchmark measurements • Comparison with Fluke • Structure • Performance

23. Platform • Base system • Kaffe Java virtual machine • Platform • Measurements from a 300 Mhz PII • Java code is JIT compiled

24. Micro-benchmarks • Alta vs. Kaffe • Basic VM operations are ~ unchanged • 50-100 cycle overhead on object allocation • Kaffe/Alta vs. Microsoft JVM • Three (or more) times slower

25. Alta vs. Fluke: Structure • Use similar internal organization • Both implement a “red line” [Back 1999] • Fully preemptible kernel • Alta allows kernel / user data sharing • Alta’s kernel is almost malloc-less • Except some JVM-internal structures

26. Alta vs. Fluke: Performance • Alta wins: • Null system call • 192 cycles (vs. 302 in Fluke) • Optimal thread switch • 185 cycles (vs. 519 in Fluke) • Fluke wins everything else, e.g., • Null IPC round trip • 18,524 cycles (64 µs) vs. 7,519 cycles in Fluke • Process creation: • ~11.9M cycles (39 ms) vs. 1M cycles in Fluke

27. Performance Evaluation • Alta hampered by poor JIT compiler • GCJ will improve this • Alta kernel is C-like • HotSpot, etc provide interesting opportunities • Alta can be optimized, too • Static definition of a typespace • Better kernel synchronization • Incorporate recent Fluke optimizations

28. Related Work: Java • [Balfanz 1998], [Bernadat 1998], [Sun 1998] • J-Kernel [Hawblitzel 1998] • Pure Java • No inter-process sharing • KaffeOS [Back 1999] • More restrictive sharing • Resource management focus • Per-process heaps • GC time accounting • ...

29. Related Work: OS • Pilot / Cedar / Mesa [Redell 1980], [Swinehart 1986] • Oberon / Juice [Franz 1996] • Inferno [Dorward 1998] • SPIN [Bershad 1995] • Vino [Seltzer 1996]

30. Future Work • Resource accounting & GC • Formal analysis of Alta type system • Fluke & Alta integration • Alta-specific applications

31. Contributions • Alta demonstrates applicability of OS abstractions to Java • The Fluke NPM with a different protection mechanism • Multiple application support in a JVM • Type-safe sharing between inconsistent typespaces