1 Supporting Hot-Swappable Components for System Software Kevin Hui, Jonathan Appavoo, Robert Wisniewski, Marc Auslander, David Edelsohn, Ben Gamsa Orran Krieger, Bryan Rosenburg, Michael Stumm HOTOS 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 1. Instantiate a replacement component 2. Quiescent state 3. Transfer state 4. Swap component 5. Deallocate the old component

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

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

8 Outline Introduction Design Overview Implementation Highlights Preliminary Results Conclusion

9 Design Overview The algorithm is as follows: 1. Establish a quiescent state 2. Transfer the component state 3. 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 1. Forward 2. Block 3. 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