1 / 22

Dynamic Software Updates: The State Mapping Problem

Dynamic Software Updates: The State Mapping Problem. 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. old. new. old. new. old.

frieda
Download Presentation

Dynamic Software Updates: The State Mapping Problem

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Dynamic Software Updates: The State Mapping Problem Rida A. BazziKristisMakris PeymanNayeri Jun Shen ARIZONA STATE UNIVERSITY

  2. The Software Update Problem • Replace an old version of an application with a new version of the application old new

  3. old new

  4. old How to affect the mapping: mechanism? How to determine if a safe mapping is possible? State mapping new

  5. THE MECHANISM: UpStare • A general mechanism for state mapping • Supports immediate updates of multi-threaded applications • Supports update for applications with blocking system calls • An application written in C is made updateable using code instrumentation

  6. UpStare’sMECHANISMS • State Reconstruction: to update active functions • Transforming blocking calls to non-blocking calls. • Forcing all threads to block before an update. • Stack reconstruction for every thread • Resumption up to the update point for all • Resumption for all

  7. STATE MAPPING in UpStare • Maps • global variables global variables • local variables local variables • Default type transformation • short to long • Float to double • .... • Default initialization • Can be overridden by user

  8. TAMING THE STATE MAPPING PROBLEM • Assumption • Some degree of backward compatibility should be expected • Approach • Ignore some differences: log functions • Reduce the state that needs to be mapped: wait for light-weight functions to exit • Take advantage of backward compatibility assumption: semantic checking with unification

  9. LIGHT WEIGHT FUNCTIONS • Functions that are guaranteed to exit in a bounded amount of time • No need to map state! • We do not solve the halting problem

  10. STRICT DEFINITION • A function as lightweight if: • Does not contain loops • Does not call itself recursively • Does not call synchronization functions (locks, semaphores, …) • Does not call a non-lightweight function • Does not read input

  11. 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 heavyweight • Any function that calls a heavyweight function is heavyweight • For the remaining functions: • Repeat until there are no changes: If a function only calls lightweight functions, add it to the list of lightweight functions

  12. LIGHT WEIGHT FUNCTIONS: INITIAL NUMBERS Moral: even simple analysis can go a long way

  13. OTHER INTERESTING STATISTICS

  14. LOG FUNCTIONS • LOG-related functions: functions that write log files • Disregard difference that are due to log function differences!!

  15. LOG FUNCTIONS: DETECTION • String arguments • Write only (fprintf, printf (not persistent), write, …) • Heavily used: no. of callers * no. of call sites • recursively : 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 them 10% of changes are due to automatically detected log functions

  16. 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 version

  17. 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 applications • Use of code slicing to compare the two executions

  18. 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 semantics • Define basic compatibility rules to be used by unification procedure • short to long • Float to double • Define constructs that can match anything (NULL constructs) • Log functions for example • Define patterns to handle control constructs • if (cond) then s1 elses2 matches s1 if cond (not unified yet) is true • if (x > y) thens1 bug fix!

  19. BUG FIXES • ... ... • if (x > y) • 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 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!

  20. BUG FIXES WITH CHECKPOINTING ... ... 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 version • Checkpoint everywhere • Check x1 > y1 at the update point • Not practical!

  21. BUG FIXES WITH CHECKPOINTING ... ... 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 • 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 environment • Re-execution simulates interactions with environment

  22. QUESTIONS?

More Related