Rida A Bazzi Kristis Makris Peyman Nayeri Jun Shen ARIZONA STATE UNIVERSITY The Software Update Problem Replace an old version of an application with a new version of the application ID: 482600
Download Presentation The PPT/PDF document "Dynamic Software Updates: The State Mapp..." is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Slide1
Dynamic Software Updates: The State Mapping Problem
Rida A.
Bazzi
Kristis
Makris
Peyman
Nayeri
Jun
Shen
ARIZONA STATE UNIVERSITYSlide2
The Software Update Problem
Replace an old version of an application with a new version of the application
old
newSlide3
old
newSlide4
old
new
State mapping
How to affect the mapping:
mechanism
?
How to determine if a
safe
mapping is possible?Slide5
THE MECHANISM: Up
Stare
A general mechanism for
state
mappingSupports immediate updates of multi-threaded applicationsSupports update for applications with blocking system callsAn application written in C is made updateable using code instrumentation Slide6
Up
Stare’
s
MECHANISMSState Reconstruction: to update active functionsTransforming blocking calls to non-blocking calls.Forcing all threads to block before an update.Stack reconstruction for every threadResumption up to the update point for allResumption for allSlide7
STATE MAPPING in Up
Stare
Maps
global variables
global variableslocal variables
local variables
Default type transformationshort to
longFloat to double....Default initializationCan be overridden by userSlide8
TAMING THE STATE MAPPING PROBLEM
Assumption
Some degree of backward compatibility should be expected
Approach
Ignore some differences: log functionsReduce the state that needs to be mapped: wait for light-weight functions to exitTake advantage of backward compatibility assumption: semantic checking with unificationSlide9
LIGHT WEIGHT FUNCTIONS
Functions that are
guaranteed
to exit in a bounded amount of timeNo need to map state!
We do not solve the halting problem Slide10
STRICT DEFINITION
A
function as lightweight
if:
Does not contain loopsDoes not call itself recursivelyDoes not call synchronization functions (locks, semaphores, …)Does not call a non-lightweight functionDoes not read inputSlide11
STRICT DETECTION
Initially, we have
Lists
of lightweight and heavyweight library functions
List of unknown library functions (we have not gone through all of them yet) Any function that does not satisfy the strict definition is heavyweightAny function that calls a heavyweight function is heavyweightFor the remaining functions:Repeat until there are no changes: If a function only calls lightweight functions, add it to the list of lightweight functions Slide12
LIGHT WEIGHT FUNCTIONS: INITIAL NUMBERS
Application
Total
Light
UnknownHeavyApache5563142150IceCast692
346131215
OpenSSH1334
4558790PostgresSQL58531236459819vsFTP6062313750
Moral: even simple analysis can go a long waySlide13
OTHER INTERESTING STATISTICS
Application
Total
Recursion
Unknown LibaryLoopsApache556619388IceCast
6928181
75OpenSSH
1334629281PostgresSQL5853141215371vsFTP6062124
15Slide14
LOG FUNCTIONS
LOG-related functions: functions that write log files
Disregard difference that are due to log function differences!!Slide15
LOG FUNCTIONS: DETECTION
String arguments
Write only (
fprintf
, printf (not persistent), write, …) Heavily used: no. of callers * no. of call sitesrecursively : called by log-functions exclusively. This is somewhat counter-intuitive and we should modify it to work bottom up.Name has log (not logarithms!)We can detect the “top” log function, but we miss some of them10% of changes are due to automatically detected log functionsSlide16
ENHANCEMENTS: BACKWARD COMPATIBLE UPDATES
if (
newOption
)
x = y*z;else x = y+z;w = x/2;x = w-z;/* update point */(b) new version
x =
y+z
;
w = x/2;x = w-z;
/* update point */
(a) Old versionSlide17
MAPPING FOR ENHANCEMENTS
How to map state so that the execution after the update is equivalent to the execution before the update?
For the example above: set
NewOption
to false In general, we need to compare the semantics of the two applicationsUse of code slicing to compare the two executionsSlide18
CODE SLICING WITH UNIFICATION
Code slicing has been used to identify components that have identical semantics
Our goal is different: we want to force to components to have
compatible
semanticsDefine basic compatibility rules to be used by unification procedureshort to longFloat to doubleDefine constructs that can match anything (NULL constructs)
Log functions for exampleDefine patterns to handle control constructsif (
cond) then s1 else
s2 matches s1 if cond (not unified yet) is trueif (x > y) then s1 bug fix! Slide19
BUG FIXES
... ...
x =
y+z
;w = x/2;x = w-z;/* update point */(a) old version
... ...
if (
x > y) x =
y+z;w = x/2;x = w-z;
/* update point */
(b) new version
The state mapping is
Impossible: cannot tell if x > y
Trivial : disregard and hope for the best:
this is the
update problem not the state repair problem!)
Not quite so!Slide20
BUG FIXES WITH CHECKPOINTING
Checkpoint everywhere
Check x1 > y1 at the update point
Not practical!
... ...
x = y+z;
w = x/2;
x = w-z;/* update point */
(a) old version ... ...
if (
x1 > y2
)
x2 =
y+z
;
w1 = x2/2;
x3 = w2-z1;
/* update point */
(b) new versionSlide21
BUG FIXES WITH CHECKPOINTING
Checkpoint at
function entry
Interactions with environment
Re-execute at time of update: should take relatively little time for non-compute bound applications Assumes no change to interfaces with environmentRe-execution simulates interactions with environment... ...
x = y+z;
w = x/2;
x = w-z;
/* update point */(a) old version
... ...
if (
x > y
)
x =
y+z
;
w = x/2;
x = w-z;
/* update point */
(b) new versionSlide22
QUESTIONS?