KaffeOS: Isolation, Resource Management and Sharing in Java

1. KaffeOS: Isolation, Resource Management and Sharing in Java Dissertation Defense Godmar Back School of Computing University of Utah

2. Motivation • Java is widely used • Examples: applets, servlets, Enterprise Java Beans, mobile agents, active packets, database procedures • Untrusted code: possibly malicious or buggy • Multiple applications on behalf of multiple users • Primary motivation  Want to provide robust environment for these applications • Secondary motivation • Make efficient use of resources; increase scalability • Run on “small” systems (handhelds, embedded systems)

3. Java Applications Applet / Agent / Servlet / Database Procedure … JVM Base OS This work is about system structure.

4. App1 App2 App3 Ad hoc layer JVM Base OS App1 App2 App3 JVM JVM JVM Base OS Current Options • Single JVM with ad-hoc layer • Efficient sharing • Multiple JVMs • Strong isolation • Good resource management

5. Java Operating System + Good isolation + Good resource management + Efficient sharing  requires process model App1 App2 App3 App4 Java OS Base OS

6. Outline • The Case for KaffeOS • KaffeOS’s Design • Isolation and Safe Termination • Memory Management • Interprocess Communication • Flexible Resource Management • Experimental Evaluation • Related Work • Future Work and Conclusion

7. KaffeOS Core Ideas

8. Cheriton 1994 The Red Line in Hardware-based OS • MMU prevents access to kernel data structures in user mode • System calls enter kernel mode

9. The Red Line for Safe Termination • Isolation of applications and system: user/kernel boundary • Kernel classes must not be corrupted • Termination is deferred while inside kernel code • All exceptional situations are handled in kernel code • NB: different from built-in synchronize

10. Guaranteeing Consistency • Producer/Consumer Example • Invariant: all produced items are consumed class Queue { synchronized Object get(); synchronized void put(Object); } Queue producer, consumer; void run () { while (!done) { Object obj = producer.get(); consumer.put(obj); } } Kernel.enter(); Kernel.leave();

11. Finalization User code (untrusted) User GC Runtime Libs (trusted) User Kernel System GC Kernel code (trusted) Red Line in KaffeOS User/kernel dimension is different from trust dimension:

12. Outline • The Case for KaffeOS • KaffeOS’s Design • Isolation and Safe Termination • Memory Management • Interprocess Communication • Flexible Resource Management • Experimental Evaluation • Related Work • Future Work and Conclusion

13. Memory Management: Goals • Limit memory use of processes • Fully reclaim processes’ memory after termination • Garbage collect processes individually

14. Single Heap (Conventional JVM) Reference Object

15. Separate Heaps Kernel Heap User Heaps Goal 1: Limit memory use

16. Reclaiming Memory • References can make objects unreclaimable

17. Legal and Illegal References Legal reference Illegal reference Goal 2: Full reclamation

18. Preventing Illegal References • Use GC write barriers • Technique used in incremental and generational collection • Intercept each write, check heaps • Throw SegmentationViolationError if illegal • Only PUTFIELD, PUTSTATIC, and AASTORE bytecode instructions have to be checked • Small cost on legal write (common case)

19. Entry Item x x Exit Item 1 RefCount n n n 2 1 x x Use of Entry and Exit Items Goal 3: Separate Collection

20. Collecting Cycles • Merge heaps upon termination into kernel heap

21. Outline • The Case for KaffeOS • KaffeOS’s Design • Isolation and Safe Termination • Memory Management • Interprocess Communication • Flexible Resource Management • Experimental Evaluation • Related Work • Future Work and Conclusion

22. IPC: Direct Sharing • Alternatives: • No sharing (copy between processes) • Indirect sharing (use proxy objects or surrogates) • Objects contain direct pointers to shared objects • Preserve Java model • Should not compromise accurate accounting or full reclamation!

23. Shared Heaps Kernel Heap Legal reference Illegal reference Shared Heap User Heap User Heap

24. Shared Heaps: Model • Accounting of shared objects • Shared heap’s size is fixed after creation • Sharers are all charged for shared heaps: double charging • Reclamation • As soon as garbage collector detects that nothing on shared heap is referenced • Restrictions on programming model • Cannot allocate new objects after heap is frozen • Cannot have references to user heaps

25. A C A B R A O F B C N T A K A Shared Heaps: Trie Example package shared; class Trie { static class TrieNode { final static int WIDTH = 96; TrieNode [] children = new TrieNode[WIDTH]; boolean eow = false; } private TrieNode root; private int maxlength; Trie(Reader r) throws IOException { … } public void dump(PrintStream s) { … } public boolean lookup(String s) { … } } import shared.Trie; Shared sh = Shared.registerClass("shared.Trie", 1); Trie trie = (Trie) sh.getObject(0); … trie.lookup(“aback”);

26. Outline • The Case for KaffeOS • KaffeOS’s Design • Isolation and Safe Termination • Memory Management • Interprocess Communication • Flexible Resource Management • Experimental Evaluation • Related Work • Future Work and Conclusion

27. Hierarchical Resource Framework • Resource API to allow for different policies • Hierarchical management • Work-conserving

28. CPU and Memory Allocation • Memory • Must not require partitioning • Soft limits: Limit overall use, allow temporary use of surplus memory • Hard limits: Provide memory guarantees if desired • CPU • Stride-scheduling for processes as a whole • Priority-based scheduler for threads in process

29. Outline • The Case for KaffeOS • KaffeOS’s Design • Experimental Evaluation • Performance for well-behaved code • Performance for adverse loads • Related Work • Future Work and Conclusion

30. Performance for Well-behaved Code • Baseline performance • Write barrier overhead • Microbenchmarks • SpecJVM98 benchmarks • Compared against • Base JVM: Kaffe (Kaffe00 from June 2000, www.kaffe.org) • IBM JDK 1.1.8 – fastest industrial 1.1 JVM • Microbenchmarks • Instruction cost: • 11 cycles minimum with one word overhead per object, 43 cycles minimum with no memory overhead

31. SpecJVM Performance of KaffeOS

32. Write Barrier Counts

33. Outline • The Case for KaffeOS • KaffeOS’s Design • Experimental Evaluation • Performance for well-behaved code • Performance for adverse loads • Related Work • Future Work and Conclusion

34. Performance for adverse loads • DOS Scenarios against • Memory • CPU • Garbage collector • KaffeOS • is more robust • delivers more effective service • improves performance under adverse loads

35. DoS Scenario • Servlet Engine: Apache 1.3.12, JServ 1.1, JSDK 2.0 • Some number of “good” servlets • Plus one MemoryHog servlet • Allocate lots of memory • Try to crash/tie up JVM • How would we deal with this? • Run 1 servlet per IBM JVM (IBM/1) • Run all servlets on one IBM JVM (IBM/n) • Run each servlet in a KaffeOS process

36. Service Under DoS Attack

37. MemHog Stresstest

38. CPU Denial of Service Scenario • Problem: cannot tell a CPU denial-of-service attack from a process doing useful work • Instead: ensure that processes obtain their share when runnable • Allow for manipulation of shares to reflect user priorities • MD5 Servlet computes MD5 hash sum over /usr/dict/word for each request • Requests/sec is measure of service

39. CpuHog Scenario

40. GarbageHog Scenario

41. Outline • The Case for KaffeOS • KaffeOS’s Design • Experimental Evaluation • Related Work • Future Work and Conclusion

42. Related Java Work • Java VMs • Multi-processing JVM [Balfanz 98] • J-Kernel [Hawblitzel et al. 98] • Alta [Tullmann 99] • IBM OS/390 JVM [Dillenberger 00] • MVM [Czajkowski 01] • JSR 121 • Java Language Extensions • Luna [Hawblitzel 99] • Java Realtime Extensions • Realtime Working Group [Sun et al. 00]

43. Related OS Work • Single-address-space OS • Opal [Chase et al. 94] • Single-language OS • Pilot [Redell et al. 80] • Cedar [Swineheart et al. 86] • Inferno [Dorward et al. 97] • Extensible OS • SPIN [Bershad et al. 95]

44. Outline • The Case for KaffeOS • KaffeOS’s Design • Experimental Evaluation • Related Work • Future Work and Conclusion

45. Future Work • JanosVM (ongoing) • Java operating system for active network node • Integration in higher-performing JVM • More accurate evaluation of costs and benefits • Static analysis using meta-level compilation • Ensure properties about user/kernel mode, shared and reloaded classes etc. statically • Automatic user-level sharing

46. Contributions • Operating system principles apply to language runtime systems • Architectural concept: user/kernel boundary • Software mechanisms can be used to implement full isolation of processes in a Java virtual machine • GC mechanisms: write barriers, distributed GC techniques • KaffeOS demonstrates how to reconcile isolation, resource management and sharing • Can stop resource-based denial-of-service attacks with small penalty for well-behaved code

47. Acknowledgments • Wilson Hsieh • Patrick Tullmann • Jason Baker • Tim Stack • Jay Lepreau and rest of Flux group for support and feedback on earlier papers

48. The End • Time for more Questions