Dynamic Software Updates: A VM-centric Approach Suriya Subramanian 1 - - PowerPoint PPT Presentation

dynamic software updates a vm centric approach
SMART_READER_LITE
LIVE PREVIEW

Dynamic Software Updates: A VM-centric Approach Suriya Subramanian 1 - - PowerPoint PPT Presentation

Dynamic Software Updates: A VM-centric Approach Suriya Subramanian 1 Michael Hicks 2 Kathryn S. McKinley 1 1 Department of Computer Sciences The University of Texas at Austin 2 Department of Computer Science University of Maryland, College Park


slide-1
SLIDE 1

Dynamic Software Updates: A VM-centric Approach

Suriya Subramanian1 Michael Hicks2 Kathryn S. McKinley1

1Department of Computer Sciences

The University of Texas at Austin

2Department of Computer Science

University of Maryland, College Park

June 16, 2009 ACM SIGPLAN PLDI 2009

slide-2
SLIDE 2

Motivation

Software applications change all the time Deployed systems must be updated with bug fixes, new features Updating typically involves: stop, apply patch, restart Not desirable

Safety concerns Revenue loss Inconvenience

Slide 2

slide-3
SLIDE 3

Dynamic software updating

Code

bytecodes machine codes

Heap Stacks

Version 1 process

Code

bytecodes machine codes

Version 2 process

Heap

Update Code Update Data Check update safety

Stacks

Update Stacks

Slide 3

slide-4
SLIDE 4

Dynamic updating systems

Special-purpose architectures, application-specific solutions exist General-purpose solutions gaining strength

K42, Ksplice for OS updates Polus, Ginseng for C applications

Not for managed languages

Slide 4

slide-5
SLIDE 5

Our solution

Jvolve - a Java Virtual Machine with DSU support Key insight: Extend existing VM services No DSU-related overhead during normal execution Support updates to real world applications Dynamic software updating in managed languages can be achieved in a safe, flexible and efficient manner by naturally extending existing VM services. DSU support should be a standard feature of future VMs.

Slide 5

slide-6
SLIDE 6

Jvolve - System overview

Foo.java Foo.java Foo.java Foo.java Foo.java Foo.java current version new version Update Preparation Tool

Jvolve Transformers.java changed methods

Code

bytecodes machine codes

Heap Stacks

... ... ...

changed classes }

Slide 6

slide-7
SLIDE 7

Supported updates

Changes within the body of a method

public static void main(String args[]) { System.out.println("Hello, World."); + System.out.println("Hello again, World."); }

Class signature updates

Add, remove, change the type signature of fields and methods

public class Line {

  • private final Point2D p1;

+ private final Point3D p1; ... }

Signature updates require an object transformer function

Slide 7

slide-8
SLIDE 8

Check for update safety

Code

bytecodes machine codes

Heap Stacks

Version 1 process

Code

bytecodes machine codes

Version 2 process

Heap

Update Code Update Data Check update safety

Stacks

Update Stacks

Slide 8

slide-9
SLIDE 9

Safe point for the update

Update must be atomic Updates happen at “safe points” Safe points are VM yield points, and restrict what methods can be on stack Extend the thread scheduler to suspend all application threads If any stack has a restricted method, delay the update

Slide 9

slide-10
SLIDE 10

Restricted methods

(1) Methods changed by the update (2) Methods identified by the user as unsafe based on semantic information about the application Install return barriers that trigger DSU upon unsafe method’s return (3) Methods whose bytecode is unchanged, but compiled representation is changed by the update

Offsets of fields and methods hard-coded in machine code Inlined callees may have changed

Utilize on-stack replacement to recompile base-compiled methods

Slide 10

slide-11
SLIDE 11

Restricted methods

(1) Methods changed by the update (2) Methods identified by the user as unsafe based on semantic information about the application Install return barriers that trigger DSU upon unsafe method’s return (3) Methods whose bytecode is unchanged, but compiled representation is changed by the update

Offsets of fields and methods hard-coded in machine code Inlined callees may have changed

Utilize on-stack replacement to recompile base-compiled methods

Slide 10

slide-12
SLIDE 12

Reaching a safe point

Modified method Group 3 method

c() d() e() Activation Stack

Grows downwards

b() a() main()

Install a return barrier for d(). Wait till it returns. On-stack replace new machine code for c().

Slide 11

slide-13
SLIDE 13

Update code

Code

bytecodes machine codes

Heap Stacks

Version 1 process

Code

bytecodes machine codes

Version 2 process

Heap

Update Code Update Data Check update safety

Stacks

Update Stacks

Slide 12

slide-14
SLIDE 14

Update code

Modify class loader to recognize new versions of classes Install new versions of classes and methods Rely on Just-in-time Compiler to compile new versions of methods on demand Extend On-stack replacement to update active methods

Slide 13

slide-15
SLIDE 15

Update data

Code

bytecodes machine codes

Heap Stacks

Version 1 process

Code

bytecodes machine codes

Version 2 process

Heap

Update Code Update Data Check update safety

Stacks

Update Stacks

Slide 14

slide-16
SLIDE 16

Example of an update (JavaEmailServer)

public class User { private final String username, domain, password;

  • private String[] forwardAddresses;

+ private EmailAddress[] forwardAddresses; public User(...) {...} public String[] getForwardedAddresses() {...} public void setForwardedAddresses(String[] f) {...} } public class ConfigurationManager { private User loadUser(...) { ... User user = new User(...); String[] f = ...; user.setForwardedAddresses(f); return user; } }

Slide 15

slide-17
SLIDE 17

Example of an update (JavaEmailServer)

public class User { private final String username, domain, password;

  • private String[] forwardAddresses;

+ private EmailAddress[] forwardAddresses; public User(...) {...}

  • public String[] getForwardedAddresses() {...}

+ public EmailAddress[] getForwardedAddresses() {...}

  • public void setForwardedAddresses(String[] f) {...}

+ public void setForwardedAddresses(EmailAddress[] f) {...} } public class ConfigurationManager { private User loadUser(...) { ... User user = new User(...);

  • String[] f = ...;

+ EmailAddress[] f = ...; user.setForwardedAddresses(f); return user; } }

Slide 16

slide-18
SLIDE 18

Example of an update (JavaEmailServer)

public class v131_User { private final String username, domain, password; private String[] forwardAddresses; } public class JvolveTransformers { ... public static void jvolveClass(User unused) {} public static void jvolveObject(User to, v131_User from) { to.username = from.username; to.domain = from.domain; to.password = from.password; // to.forwardAddresses = null; int len = from.forwardAddresses.length; to.forwardAddresses = new EmailAddress[len]; for (int i = 0; i < len; i++) { to.forwardAddresses[i] = new EmailAddress(from.forwardAddresses[i]); }}}

Slide 17

Default transformer copies

  • ld fields, initializes new
  • nes to null

Stub generated by UPT for the old version

slide-19
SLIDE 19

Example of an update (JavaEmailServer)

public class v131_User { private final String username, domain, password; private String[] forwardAddresses; } public class JvolveTransformers { ... public static void jvolveClass(User unused) {} public static void jvolveObject(User to, v131_User from) { to.username = from.username; to.domain = from.domain; to.password = from.password; // to.forwardAddresses = null; int len = from.forwardAddresses.length; to.forwardAddresses = new EmailAddress[len]; for (int i = 0; i < len; i++) { to.forwardAddresses[i] = new EmailAddress(from.forwardAddresses[i]); }}}

Slide 17

Stub generated by UPT for the old version

slide-20
SLIDE 20

Transforming objects in the GC

a b c a b c Before After

Happens in two steps Garbage collector creates an additional empty copy for updated

  • bjects

Walk through and transform all these objects

Slide 18

slide-21
SLIDE 21

Jvolve GC

To space (old version objects) To space From space a b c

Slide 19

slide-22
SLIDE 22

Jvolve GC

To space (old version objects) To space From space a b c a b c

Pointer Forwarding pointer

Slide 19

slide-23
SLIDE 23

Jvolve GC

To space (old version objects) To space From space a b c a b c

Pointer Forwarding pointer

jvolveObject(Node to,

  • ld_Node from) {

to.data = from.data; to.next = from.next; if (to.next != null) { to.next.prev = to; } }

Slide 19

slide-24
SLIDE 24

Jvolve GC

To space (old version objects) To space From space b a b c a b c

Pointer Forwarding pointer

jvolveObject(Node to,

  • ld_Node from) {

to.data = from.data; to.next = from.next; if (to.next != null) { to.next.prev = to; } }

Slide 19

slide-25
SLIDE 25

Jvolve GC

To space (old version objects) To space From space b a b c a b c

Pointer Forwarding pointer

jvolveObject(Node to,

  • ld_Node from) {

to.data = from.data; to.next = from.next; if (to.next != null) { to.next.prev = to; } }

Slide 19

slide-26
SLIDE 26

Jvolve GC

To space (old version objects) To space From space b a b c a b c

Pointer Forwarding pointer

jvolveObject(Node to,

  • ld_Node from) {

to.data = from.data; to.next = from.next; if (to.next != null) { to.next.prev = to; } }

Slide 19

slide-27
SLIDE 27

Jvolve GC

To space (old version objects) To space From space b a b c a b c

Pointer Forwarding pointer

Slide 19

slide-28
SLIDE 28

Jvolve GC

To space (old version objects) To space From space a b c a b c a b c

Pointer Forwarding pointer

Slide 19

slide-29
SLIDE 29

Jvolve GC

To space (old version objects) To space From space a b c

Slide 19

slide-30
SLIDE 30

Application Experience

Jetty webserver

11 versions, 5.1.0 through 5.1.10, 1.5 years 45 KLOC

JavaEmailServer

10 versions, 1.2.1 through 1.4, 2 years 4 KLOC

CrossFTP server

4 versions, 1.05 through 1.08, more than a year 18 KLOC

Slide 20

slide-31
SLIDE 31

What works Support 20 of 22 updates

13 updates change class signature by adding new fields Several updates require On-stack replacement support Two versions update an infinite loop, postponing the update indefinitely

Slide 21

slide-32
SLIDE 32

Jvolve performance No overhead during steady-state execution

Jvolve Jvolve (updated)

Configuration

121.0 121.1 121.2 121.3 121.4 121.5

Throughput (MB/s) Throughput

0.30 0.32 0.34 0.36 0.38

Latency (ms) Latency

Slide 22

slide-33
SLIDE 33

Conclusion

Jvolve, a Java VM with support for Dynamic Software Updating Most-featured, best-performing DSU system for Java Naturally extends existing VM services Supports about two years worth of updates Dynamic software updating in managed languages can be achieved in a safe, flexible and efficient manner. Source code and other information: http://www.cs.utexas.edu/~suriya/jvolve

Slide 23