Dynamic Software Updates: The State Mapping Problem Rida A. Bazzi Kristis Makris Peyman Nayeri Jun Shen ARIZONA STATE UNIVERSITY.

Slides:



Advertisements
Similar presentations
Program verification: flowchart programs Book: chapter 7.
Advertisements

Program verification: flowchart programs Book: chapter 7.
Operating Systems: Monitors 1 Monitors (C.A.R. Hoare) higher level construct than semaphores a package of grouped procedures, variables and data i.e. object.
Mutual Exclusion – SW & HW By Oded Regev. Outline: Short review on the Bakery algorithm Short review on the Bakery algorithm Black & White Algorithm Black.
While loops.
Operating Systems Lecture 7.
Mapping Site Instruments. Introduction The Mapped Instrument is a tool that guides you in matching your site specific Instrument and materials to the.
Chapter 16: Recovery System
 Read about Therac-25 at  [  [
1 CPS216: Data-intensive Computing Systems Failure Recovery Shivnath Babu.
1 Regression-Verification Benny Godlin Ofer Strichman Technion.
1 1 Regression Verification for Multi-Threaded Programs Sagar Chaki, SEI-Pittsburgh Arie Gurfinkel, SEI-Pittsburgh Ofer Strichman, Technion-Haifa Originally.
A Randomized Dynamic Program Analysis for Detecting Real Deadlocks Koushik Sen CS 265.
Ch. 7 Process Synchronization (1/2) I Background F Producer - Consumer process :  Compiler, Assembler, Loader, · · · · · · F Bounded buffer.
Mutual Exclusion By Shiran Mizrahi. Critical Section class Counter { private int value = 1; //counter starts at one public Counter(int c) { //constructor.
Lecture 5 Concurrency and Process/Thread Synchronization     Mutual Exclusion         Dekker's Algorithm         Lamport's Bakery Algorithm.
Silberschatz, Galvin and Gagne ©2013 Operating System Concepts – 9 th Edition Chapter 5: Process Synchronization.
5.1 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts with Java – 8 th Edition Chapter 5: CPU Scheduling.
Multiprocessor Synchronization Algorithms ( ) Lecturer: Danny Hendler The Mutual Exclusion problem.
Concurrency.
CS 536 Spring Global Optimizations Lecture 23.
Concurrency in Ada What concurrency is all about Relation to operating systems Language facilities vs library packages POSIX threads Ada concurrency Real.
4/25/08Prof. Hilfinger CS164 Lecture 371 Global Optimization Lecture 37 (From notes by R. Bodik & G. Necula)
Synchronization Principles. Race Conditions Race Conditions: An Example spooler directory out in 4 7 somefile.txt list.c scores.txt Process.
Prof. Fateman CS 164 Lecture 221 Global Optimization Lecture 22.
29-Jun-15 Java Concurrency. Definitions Parallel processes—two or more Threads are running simultaneously, on different cores (processors), in the same.
Prof. Bodik CS 164 Lecture 16, Fall Global Optimization Lecture 16.
The Critical Section Problem
Concurrency, Mutual Exclusion and Synchronization.
Computer Science Detecting Memory Access Errors via Illegal Write Monitoring Ongoing Research by Emre Can Sezer.
1cs Intersection of Concurrent Accesses A fundamental property of Web sites: Concurrent accesses by multiple users Concurrent accesses intersect.
111 © 2002, Cisco Systems, Inc. All rights reserved.
Games Development 2 Concurrent Programming CO3301 Week 9.
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University IWPSE 2003 Program.
CS510 Concurrent Systems Jonathan Walpole. A Methodology for Implementing Highly Concurrent Data Objects.
13-1 Chapter 13 Concurrency Topics Introduction Introduction to Subprogram-Level Concurrency Semaphores Monitors Message Passing Java Threads C# Threads.
CSE 311 Foundations of Computing I Lecture 28 Computability: Other Undecidable Problems Autumn 2011 CSE 3111.
Lecture 3 Concurrency and Thread Synchronization     Mutual Exclusion         Dekker's Algorithm         Lamport's Bakery Algorithm.
Recursively Enumerable and Recursive Languages
Process Synchronization. Objectives To introduce the critical-section problem, whose solutions can be used to ensure the consistency of shared data To.
1 Recursively Enumerable and Recursive Languages.
1 Immediate Multi-Threaded Dynamic Software Updates Using Stack Reconstruction Kristis Makris Rida A. Bazzi
CS314 – Section 5 Recitation 9
Process Synchronization: Semaphores
Background on the need for Synchronization
Day 12 Threads.
Chapter 9 Recursion.
Reasoning About Code.
Reasoning about code CSE 331 University of Washington.
C-language Lecture By B.S.S.Tejesh, S.Neeraja Asst.Prof.
Sentinel logic, flags, break Taken from notes by Dr. Neil Moore
143a discussion session week 3
CSE 105 theory of computation
Sentinel logic, flags, break Taken from notes by Dr. Neil Moore
Lecture 14: Pthreads Mutex and Condition Variables
Java Concurrency 17-Jan-19.
Test Case Test case Describes an input Description and an expected output Description. Test case ID Section 1: Before execution Section 2: After execution.
Concurrency: Mutual Exclusion and Process Synchronization
Lecture 14: Pthreads Mutex and Condition Variables
Lecture 2 The Art of Concurrency
Loop Construct.
Java Concurrency.
CSE 153 Design of Operating Systems Winter 19
ECE 103 Engineering Programming Chapter 18 Iteration
Java Concurrency.
Foundations and Definitions
Java Concurrency 29-May-19.
CSE 105 theory of computation
Chapter 15 Debugging.
Presentation transcript:

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 oldnew

old new

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

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

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

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

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

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

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

LIGHT WEIGHT FUNCTIONS: INITIAL NUMBERS ApplicationTotalLightUnknownHeavy Apache IceCast OpenSSH PostgresSQL vsFTP Moral: even simple analysis can go a long way

OTHER INTERESTING STATISTICS ApplicationTotalRecursionUnknown Libary Loops Apache IceCast OpenSSH PostgresSQ L vsFTP

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

LOG FUNCTIONS: DETECTION 1.String arguments 2.Write only (fprintf, printf (not persistent), write, …) 3.Heavily used: no. of callers * no. of call sites 4.recursively : called by log-functions exclusively. This is somewhat counter-intuitive and we should modify it to work bottom up. 5.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

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

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

CODE SLICING WITH UNIFICATION

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!

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 version

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 environment – Re-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 version

QUESTIONS?