Hung, Chin-Chieh ESL, Dept. of CSIE , CCU 8/25/2005

1. Supporting Hot-Swappable Components for System SoftwareKevin Hui, Jonathan Appavoo, Robert Wisniewski, Marc Auslander, David Edelsohn, Ben GamsaOrran Krieger, Bryan Rosenburg, Michael StummHOTOS 2001 Hung, Chin-Chieh ESL, Dept. of CSIE , CCU 8/25/2005

2. Outline • Introduction • Design Overview • Implementation Highlights • Preliminary Results • Conclusion

3. Outline • Introduction • Design Overview • Implementation Highlights • Preliminary Results • Conclusion

4. Introduction • A hot-swappable component • Can be replace at running time • Online upgrades • Improve performance • Simplify software

5. Introduction • The necessary of hot-swappable component • Instantiate a replacement component • Quiescent state • Transfer state • Swap component • Deallocate the old component

6. Problemsof Hot-Swappable Component • Establish a quiescent state • Safely transfer and swap • Transfer state • The most easy way is not efficient • Swap all of the references held by client • The references now refer to the new one

7. Design Goals • Zero performance overhead for that will not be swapped • Complete transparency to client component • Minimal code impact on components that wish to be swaped • Zero impact on other components • Good performance and scalability

8. Outline • Introduction • Design Overview • Implementation Highlights • Preliminary Results • Conclusion

9. Design Overview • The algorithm is as follows: • Establish a quiescent state • Transfer the component state • Update the references to the component

10. Establish a quiescent state • Swap the indirection pointer • Point to an interposing object • Track all thread • Could pass the call to original object • Wait for the termination of all calls • Use a efficient means • Blocks all new call

11. Transfer the component state • Best common format • To make state transfer efficient • Avoid canonical form • A list or array • For example • A hash table to be passed directly through a pointer

12. Update the references to the component • Changing the indirection pointer • Refer to the new object • Relesaing all the threads blocked in the interposing object • Deallocating the original object and the temporary interposing object

13. Outline • Introduction • Design Overview • Implementation Highlights • Preliminary Results • Conclusion

14. Implementation Highlights • The interposing object is called the mediator • Three phases of the swapping operation • Forward • Block • Completed

15. Forward Phase • Tracks new incoming calls • By identifiers and increments an in-flight call counter • Stores thread identifiers • In a hash table • This phase continues until the swap initiation has the lowest generation number • A generation number in K42

16. Block Phase • Check the new call • Belong to the in-flight thread(in hash table) • Yes, forward to the original component • No, the thread is suspended • The call counter reached 0 • A quiescent state

17. Completed Phase • Remove the mediator • Future call be directly handled by the new component • Resume all thread

18. Outline • Introduction • Design Overview • Implementation Highlights • Preliminary Results • Conclusion

19. Preliminary Results • Benchmarks • A toy component (simple counter) • A substantial component of the K42 memory management subsystem

20. Preliminary Results • Counter • Simple:Partitioned/Shared counter

21. Preliminary Results • File Cache Manager(FCM) • Simple:Partitioned/Shared FCM

22. Outline • Introduction • Design Overview • Implementation Highlights • Preliminary Results • Conclusion

23. Conclusion • Describe the hot-swapping mechanism • Totally transparent to the clients • Minimize Impact on performance • The limitation of this mechanism • Threads are relatively short-lived • Many Server-based system are short-lived

24. Thanks for your listening