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 StummHOTOS 2001

Hung, Chin-ChiehESL, 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 component2. Quiescent state3. Transfer state4. Swap component5. 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 components5. 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 state2. Transfer the component state3. 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 i

nterposing object Deallocating the original object and the t

emporary 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. Forward2. Block3. 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 tabl

e) 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