in DSU and providing it with an effective approach.The rest of 1class SocketProcessor 2-private NioChannel socket null; the paper is organized as follows.Section II gives the necessary 3+private KeyAttachment ka null; background knowledge of DSU with a motivating example. 4 private SocketStatus status null; Section IlI presents a comprehensive study on DSU of 190 s public void run(){ 6+ NioChannel socket ka.getSocket(); class changes in Tomcat 8.Our DSL and synthesis algorithm 7 SelectionKey key socket.getIOChannel().keyFor( are elaborated on in Sections IV and V,respectively.The socket.getPoller().getSelector()); evaluation of PASTA against real-world updates is described 9- KeyAttachment ka null; 18- in Section VI,followed by threats to validity discussions in if (key !null) 11 ka =(KeyAttachment)key.attachment() Section VⅡ，related work in Section VⅢ，and conclusion in 12 Section IX. 13] 14 II.BACKGROUND AND MOTIVATION 1sclass DSUHelper 16 static void transform(SocketProcessor*obj,SocketProcessor stale){ A.DSU Systems and Object Transformation 17 /trivial default transformation for status obj.status stale.status; This paper focuses on the DSU of Java programs',which 18 19 /non-trivial transformation for ka consists of the following four steps: 28 obj.ka null; 1)Pause the program under update at a safe point [10,31], NioChannel socket stale.socket; if (socket !null){ e.g.,when all updated code is popped off the stack [15,17]. 23 SelectionKey key socket.getIoChannel().keyFor( 2)Upgrade the changed code [32,33]via dynamic link- 24 socket.getPoller().getSelector()); ing [34],live patching [10],or hotswap [26]. 25 if (key !null) 6 obj.ka (KeyAttachment)key.attachment(); 3)Transform stale (old-version)objects in the heap to their 27 new state [27,281. 28 4)Resume the updated program's execution.The new version 29] is now ready to serve. Fig.1:A class change in Tomcat-8(commit #f4451c)whose Object transformation(the third step)is this paper's primary object transformation is non-trivial.DSUHelper is our manually focus.When a program is paused at an update-safe point provided object transformer.At update time,the DSU system with code being upgraded,the heap may contain stale objects for each(stale)object sp (of type SocketProcessor)creates whose values are inconsistent with the new-version code.A its corresponding uninitialized new-version object sp*(of type DSU system must for each such object invoke its transformer SocketProcessor",the same class after update)and invokes to migrate to its corresponding new-version. the object transformer DSUHelper.transform(sp*,sp). B.Motivating Example Figure I lists a class change to SocketProcessor,which the latter is typically lacking for most application developers. requires a non-trivial transformation.This class change replaces Sometimes,a DSU system may automatically synthesize a the socket field by ka with a type change from NioChannel non-trivial object transformer,however,our empirical study to KeyAttachment (Lines 2-3).We correspondingly provide results in Section III show that existing techniques fall short on an object transformer DSUHelper.transform(Lines 16-28). most real-world cases.For this motivating example,TOS [27] The status field undergoes a default (or trivial)transfor- incorrectly falls back to the default null assignment because mation:it inherits its value from the old-version (Line 18).the non-trivial transformer is beyond TOS's search capability A default transformation copies the old-version value for a AOTES [28]also fails in synthesizing a method history for type-unchanged field or assigns a default value (e.g.,0 for int such complex objects. and null for references)to a newly-added field [15,17]. C.Discussions However,the ka field requires a non-trivial transformation If we leave ka with a default null reference,the program will Interestingly,the key non-trivial step in our manually quickly crash after DSU.Our transformer in Figure 1 leverages provided transformer,which retrieves the SelectionKey from the program's implicit invariant that there is a 1-to-1 mapping an NioChannel object in Lines 23-24,is identical to the code between NioChannel objects and KeyAttachment objects in in Lines 7-8.The null-check in the transformer (Lines 25-26) the heap.Lines 21-26 invoke a chain of I/O channel APIs to can also be found in the old-version code (Lines 10-11),which find stale.socket's corresponding KeyAttachment object. is removed in the new version because the local variable ka is Providing non-trivial object transformers is considerably available through the newly added field (Line 3). challenging even for experienced developers:it requires ex- This should not be considered completely incidental.If pertise in both the application logic and DSU system,where there is a code snippet for computing an object's property that reflects an internal invariant(potentially useful for object IDSU and object transformation for unmanaged heaps (e.g.,C/C++)are transformation like the code that finds the SelectionKey for considerably different and are out of this paper's scope.However,arguments a given NioChannel object),the code snippet might also be in this paper can also be applied to other managed runtime systems. 2An object transformer is considered trivial if it contains only default useful to other parts of the program and is likely to exist in transformations,otherwise is non-trivial. the source code.in DSU and providing it with an effective approach. The rest of the paper is organized as follows. Section II gives the necessary background knowledge of DSU with a motivating example. Section III presents a comprehensive study on DSU of 190 class changes in Tomcat 8. Our DSL and synthesis algorithm are elaborated on in Sections IV and V, respectively. The evaluation of PASTA against real-world updates is described in Section VI, followed by threats to validity discussions in Section VII, related work in Section VIII, and conclusion in Section IX. II. BACKGROUND AND MOTIVATION A. DSU Systems and Object Transformation This paper focuses on the DSU of Java programs1 , which consists of the following four steps: 1) Pause the program under update at a safe point [10, 31], e.g., when all updated code is popped off the stack [15, 17]. 2) Upgrade the changed code [32, 33] via dynamic link￾ing [34], live patching [10], or hotswap [26]. 3) Transform stale (old-version) objects in the heap to their new state [27, 28]. 4) Resume the updated program’s execution. The new version is now ready to serve. Object transformation (the third step) is this paper’s primary focus. When a program is paused at an update-safe point with code being upgraded, the heap may contain stale objects whose values are inconsistent with the new-version code. A DSU system must for each such object invoke its transformer to migrate to its corresponding new-version. B. Motivating Example Figure 1 lists a class change to SocketProcessor, which requires a non-trivial transformation. This class change replaces the socket field by ka with a type change from NioChannel to KeyAttachment (Lines 2–3). We correspondingly provide an object transformer DSUHelper.transform (Lines 16–28). The status field undergoes a default (or trivial) transfor￾mation: it inherits its value from the old-version (Line 18). A default transformation copies the old-version value for a type-unchanged field or assigns a default value (e.g., 0 for int and null for references) to a newly-added field [15, 17]. However, the ka field requires a non-trivial transformation2 . If we leave ka with a default null reference, the program will quickly crash after DSU. Our transformer in Figure 1 leverages the program’s implicit invariant that there is a 1-to-1 mapping between NioChannel objects and KeyAttachment objects in the heap. Lines 21–26 invoke a chain of I/O channel APIs to find stale.socket’s corresponding KeyAttachment object. Providing non-trivial object transformers is considerably challenging even for experienced developers: it requires ex￾pertise in both the application logic and DSU system, where 1DSU and object transformation for unmanaged heaps (e.g., C/C++) are considerably different and are out of this paper’s scope. However, arguments in this paper can also be applied to other managed runtime systems. 2An object transformer is considered trivial if it contains only default transformations, otherwise is non-trivial. 1 class SocketProcessor { 2 - private NioChannel socket = null; 3 + private KeyAttachment ka = null; 4 private SocketStatus status = null; 5 public void run() { 6 + NioChannel socket = ka.getSocket(); 7 SelectionKey key = socket.getIOChannel().keyFor( 8 socket.getPoller().getSelector()); 9 - KeyAttachment ka = null; 10 - if (key != null) 11 - ka = (KeyAttachment)key.attachment(); 12 ... } ... 13 } 14 15 class DSUHelper { 16 static void transform(SocketProcessor? obj, SocketProcessor stale) { 17 // trivial default transformation for status 18 obj.status = stale.status; 19 // non-trivial transformation for ka 20 obj.ka = null; 21 NioChannel socket = stale.socket; 22 if (socket != null) { 23 SelectionKey key = socket.getIOChannel().keyFor( 24 socket.getPoller().getSelector()); 25 if (key != null) 26 obj.ka = (KeyAttachment)key.attachment(); 27 } 28 } 29 } Fig. 1: A class change in Tomcat-8 (commit #f4451c) whose object transformation is non-trivial. DSUHelper is our manually provided object transformer. At update time, the DSU system for each (stale) object sp (of type SocketProcessor) creates its corresponding uninitialized new-version object sp? (of type SocketProcessor? , the same class after update) and invokes the object transformer DSUHelper.transform(sp?, sp). the latter is typically lacking for most application developers. Sometimes, a DSU system may automatically synthesize a non-trivial object transformer, however, our empirical study results in Section III show that existing techniques fall short on most real-world cases. For this motivating example, TOS [27] incorrectly falls back to the default null assignment because the non-trivial transformer is beyond TOS’s search capability. AOTES [28] also fails in synthesizing a method history for such complex objects. C. Discussions Interestingly, the key non-trivial step in our manually provided transformer, which retrieves the SelectionKey from an NioChannel object in Lines 23–24, is identical to the code in Lines 7–8. The null-check in the transformer (Lines 25–26) can also be found in the old-version code (Lines 10–11), which is removed in the new version because the local variable ka is available through the newly added field (Line 3). This should not be considered completely incidental. If there is a code snippet for computing an object’s property that reflects an internal invariant (potentially useful for object transformation like the code that finds the SelectionKey for a given NioChannel object), the code snippet might also be useful to other parts of the program and is likely to exist in the source code