Immediate Multi-Threaded Dynamic Software Updates Using Stack - - PowerPoint PPT Presentation

▶
immediate multi threaded dynamic software updates using
SMART_READER_LITE
LIVE PREVIEW

Immediate Multi-Threaded Dynamic Software Updates Using Stack - - PowerPoint PPT Presentation

Dec 23, 2022 151 likes •590 views

Immediate Multi-Threaded Dynamic Software Updates Using Stack Reconstruction Kristis Makris Rida A. Bazzi {makristis,bazzi}@asu.edu 1 Motivation Software update problem: replace old version with new version Traditional

slide-1
SLIDE 1

1

Immediate Multi-Threaded Dynamic Software Updates Using Stack Reconstruction

Kristis Makris Rida A. Bazzi {makristis,bazzi}@asu.edu

slide-2
SLIDE 2

2

Motivation

 Software update problem: replace old

version with new version

 Traditional approach is static:

– stop, update, restart – Impairs high-availability

 Dynamic software update (DSU) can help

minimize downtime

slide-3
SLIDE 3

3

main f g h main f

Stack Execution trace

g

request update

h

g

slide-4
SLIDE 4

4

main f g h main f

Stack Execution trace

g

request update

h

g

h

g f

?

g g

slide-5
SLIDE 5

5

 Type-safety: No old code executed on new data; and vice versa

typedef struct { char name[64]; float balance; } customer_record_v1_t;

  • ld version

typedef struct { char name[64]; int number_of_accesses; float balance; } customer_record_v2_t;

new version 0.0 John memory alignment f() writes balance = 145.0 145.0 John memory alignment 145

g() is called data are transformed

g() writes balance = 160.0 160

g() returns; f() executes

f() reads incorrect balance = 0

slide-6
SLIDE 6

6

main f g h main f

Stack Execution trace

g

request update

h

g

h

g f

g h

g f main  Is old version in valid state ?  Is there a valid mapping ?  Undecidable problem – Need user input  Should provide useful

safety guarantees

slide-7
SLIDE 7

7

main f g h main f

Stack Execution trace

g

request update

h

g

h

g f

g h

g f main

f g h

update finished  Undecidable problem – Need user input  Should provide useful

safety guarantees

slide-8
SLIDE 8

8

Useful DSU Safety Guarantees

 Atomic update (subsumes type-safety)  Transaction-safety  Thread-safety

slide-9
SLIDE 9

9

Atomic Update

–

At no time does the executing application expect different representations of state

–

After the update only new code executes over the new state; no old code ever executes again

hybrid execution

new version

resume map state pause

  • ld version
slide-10
SLIDE 10

10

Transaction-safety

 Some code executes only in old or only in new version  Requires user annotations

f() { ... while(condition) { i(); j(); k(); } ... }

do not update inside region

slide-11
SLIDE 11

11

Thread-safety

while (condition) { recv(&data); process(&data); }

server clients active connections new connections active connections new connections

  • ld code

active connections new connections new code

1. 2. 3.

slide-12
SLIDE 12

12

Providing thread-safety requires immediate updates

– Atomic update – Bounded delay

Existing DSU mechanisms do not provide support for immediate updates

slide-13
SLIDE 13

13

Our Results

 First general DSU mechanism that

supports

– Immediate updates

 Atomic update  Bounded delay  Multi-threaded

– Update active code and data – Low data-access overhead

slide-14
SLIDE 14

14

Our Approach: UpStare

 Compiler, patch-generator, runtime

– Insert update points – Source-to-source transformations of C programs – Architecture and OS independent

 Immediate multi-threaded updates

– Atomic update: using stack reconstruction – Bounded delay: converting blocking calls to non-

blocking

– Multithreaded: safely blocking all threads

slide-15
SLIDE 15

15

block until unroll finishes

Stack Reconstruction: unrolling

main() _main() a() b() c() e() f() g() main() _main() a() b() c() d() i() _i() k() m() Thread 1 Thread 2 Thread 3

g() f() e() c() b() a() _main() m() k() _i() d() c() b() a() _main()

saved frames saved frames saved frames block all threads map global variables

slide-16
SLIDE 16

16

Stack Reconstruction: restoring

main() _main() a() b() c() e() d() main() _main() a() b() c() d() i() _i_new() k() m() Thread 1 Thread 2 Thread 3

g() f() e() c() b() a() _main() m() k() _i() d() c() b() a() _main()

saved frames saved frames saved frames p() copy copy map

  • Can update:
  • local variables
  • formal parameters
  • return addresses
  • Program Counter

apply stack transformers

  • split functions
  • map continuation
  • merge functions together
slide-17
SLIDE 17

17

Continuation Points

main() { UPDATE_POINT(); a(); c(); g(); } a() { UPDATE_POINT(); b(); } b() { UPDATE_POINT(); d(); while(condition) { UPDATE_POINT(); e(); }

main() _main()

  • ld version
slide-18
SLIDE 18

18

Continuation Points

main() { UPDATE_POINT(); a(); c(); g(); } a() { UPDATE_POINT(); b(); } b() { UPDATE_POINT(); d(); while(condition) { UPDATE_POINT(); e(); }

main() _main()

  • ld version
slide-19
SLIDE 19

19

Continuation Points

main() { UPDATE_POINT(); a(); c(); g(); } a() { UPDATE_POINT(); b(); } b() { UPDATE_POINT(); d(); while(condition) { UPDATE_POINT(); e(); }

main() _main() a()

  • ld version
slide-20
SLIDE 20

20

Continuation Points

main() { UPDATE_POINT(); a(); c(); g(); } a() { UPDATE_POINT(); b(); } b() { UPDATE_POINT(); d(); while(condition) { UPDATE_POINT(); e(); }

main() _main() a()

  • ld version
slide-21
SLIDE 21

21

Continuation Points

main() { UPDATE_POINT(); a(); c(); g(); } a() { UPDATE_POINT(); b(); } b() { UPDATE_POINT(); d(); while(condition) { UPDATE_POINT(); e(); }

main() _main() a() b()

  • ld version
slide-22
SLIDE 22

22

Continuation Points

main() { UPDATE_POINT(); a(); c(); g(); } a() { UPDATE_POINT(); b(); } b() { UPDATE_POINT(); d(); while(condition) { UPDATE_POINT(); e(); }

main() _main() a() b() d()

  • ld version
slide-23
SLIDE 23

23

Continuation Points

main() { UPDATE_POINT(); a(); c(); g(); } a() { UPDATE_POINT(); b(); } b() { UPDATE_POINT(); d(); while(condition) { UPDATE_POINT(); e(); }

main() _main() a() b()

  • ld version
slide-24
SLIDE 24

24

Continuation Points

main() { UPDATE_POINT(); a(); c(); g(); } a() { UPDATE_POINT(); b(); } b() { UPDATE_POINT(); // CP 1 d(); // CP 2 while(condition) { UPDATE_POINT(); // CP 3 e(); // CP 4 }

main() _main() a() b() Saved continuation points: b_CP_3 initiate an update

  • ld version
slide-25
SLIDE 25

25

Continuation Points

main() { UPDATE_POINT(); a(); c(); g(); } a() { UPDATE_POINT(); // CP 1 b(); // CP 2 }

main() _main() a() Saved continuation points: b_CP_3 a_CP_2

slide-26
SLIDE 26

26

Continuation Points

main() { UPDATE_POINT(); // CP 1 a(); // CP 2 c(); // CP 3 g(); // CP 4 }

main() _main() Saved continuation points: b_CP_3 a_CP_2 _main_CP_2

slide-27
SLIDE 27

27

Continuation Points

main() _main() Saved continuation points: b_CP_3 a_CP_2 _main_CP_2 Restored continuation points: _main_CP_2

main() { UPDATE_POINT(); a(); // CP 2 c(); g(); }

new version

slide-28
SLIDE 28

28

Continuation Points

main() _main() Saved continuation points: b_CP_3 a_CP_2 _main_CP_2 Restored continuation points: _main_CP_2 new version

main() { UPDATE_POINT(); a(); // CP 2 c(); g(); } a() { UPDATE_POINT(); b(); // CP 2 }

a() a_CP_2

slide-29
SLIDE 29

29

main() { UPDATE_POINT(); a(); c(); g(); } a() { UPDATE_POINT(); b(); } b() { UPDATE_POINT(); // CP 1 d(); // CP 2 f(); // CP 3 while(condition) { UPDATE_POINT(); // CP 4 e(); // CP 5 }

Continuation Points

main() _main() a() Saved continuation points: b_CP_3 a_CP_2 _main_CP_2 Restored continuation points: _main_CP_2 a_CP_2 b_CP_4 b() new version

slide-30
SLIDE 30

30

Multi-Threaded Updates

HAS lock L WANTS lock L

voluntarily blocked blocked

Thread 1 Thread 2

LOCK(L); UPDATE_POINT(); LOCK(L);

  • Detect if all threads are blocked
  • Treat locks as update points

Multi-Process Updates

  • wrap fork(), wait(), waitpid()
  • coordinate atomic reconstruction
slide-31
SLIDE 31

31

Bounded Delay

SOME DATA 0000000000 0000000000 0000000000 stack data buffer YYYYYYYYYYY ZZZZZZZZZZ

  • ther data

functionA() { char data[SIZE]; ... recv(FD, &data); ... }

heap SOME DATA 0000000000 0000000000 0000000000 save issue non-blocking XXXXXXXXX XXXXXXXXX XXXXXXXXX XXXXXXXXX SOME DATA MORE DATA 0000000000 0000000000 voluntarily block restore SOME DATA MORE DATA 0000000000 0000000000

RECV(FD,&data); SELECT(FD); UPDATE_POINT(); RECV_FINISH(FD,&data);

slide-32
SLIDE 32

32

Evaluation

 KissFFT

– Small, data-intensive application (2,000 LoC)

 Very Secure FTP Daemon

– Medium-sized application (12,000 LoC) – Forks non-communicating connection handlers

 PostgreSQL DBMS

– Large application (postmaster: 225,000 LoC) – Forks communicating connection handlers

 Shared Memory

slide-33
SLIDE 33

33

KissFFT v1.2.0

 Overhead

– Execution time: 38%; faster than Ginseng (150%) functionA functionB uninstrumented version desired

  • ptimization
  • utside .text

segment code for restoring instrumented version code for unrolling code for update points

slide-34
SLIDE 34

34

Very Secure FTP Daemon

 Updates

– Under two use cases: idle client, file transfer – 13 updates (5.5 years-worth) – 11 manual continuation mappings – Latency 60ms (50ms to block all threads)

 Overhead

– Latency: retrieve a 32-byte file 1000 times – Throughput: retrieve a 300MB file – In-memory and on-disk, over cross-over cable

slide-35
SLIDE 35

35

vsFTPd Overhead

 Latency: 16-17% (1.6ms); throughput: 0%

slide-36
SLIDE 36

36

PostgreSQL DBMS

 Updates

– 1 update: v7.4.16 to v7.4.17 – No manual continuation points; latency 60ms

 Overhead

– Latency: run 1 transaction 1000 times – Throughput: “TPC-B like” pgbench; 100,000 txs – In-memory and on-disk, over cross-over cable

slide-37
SLIDE 37

37

PostgreSQL Latency

 Latency: 89-97% (22.5ms)

slide-38
SLIDE 38

38

PostgreSQL Throughput

 Throughput: 41% in-memory; 26% on-disk

slide-39
SLIDE 39

39

Related Work

 Application DSU

– OPUS: Small, isolated, feature-less updates – POLUS: Cannot update local variables – Ginseng: Data-access indirection

 Kernel DSU

– DynAMOS,KSplice

 Data-access indirection; limited safety

– K42: Immediate updates; specially crafted

slide-40
SLIDE 40

40

On-going and Future Work

 Move cold code at end of process image  Automatically map pointers

– Developed in previous work; not integrated yet

 Runtime safety checking

– Transaction-safety through dynamic stack tracing

 Temporary overhead 10-12%

 Semantic analysis

– Identify nature of updates and prove correctness – Reduce user input

 Update in-transit data and files

slide-41
SLIDE 41

41

Conclusion

 UpStare: Dynamic Software Updating

– Source-to-source transformation of C applications – Useful safety guarantees

 Stack reconstruction

– Update active code and data atomically – No data-access indirection

 Multi-threaded and multi-process updates  Immediate updates

– Convert blocking calls to non-blocking

 Demonstrated updates

– vsFTPd: 13 updates (5.5 years-worth); 12,000 LOC – PostgreSQL v7.4.16; over 200,000 LOC

 Low overhead (0-26%); unoptimized

slide-42
SLIDE 42

42

Questions ?