Chronon - A Back-In-Time-Debugger for Java

Chronon - A Back-In-Time-Debugger for Java

• 1.
  Chronon A Back-In-TimeDebugger For Java Tobias Sauerwein Software Analysis – Summer Semester 2011
• 2.
  Overview • Introduction • Technical Concept • Comparison: ObjectFlow Debugger (Paper) – Chronon • Demonstration – General Usage – Multi-Threaded Program • Performance Evaluation • Conclusion – Limitations – Advantages 2 / 30
• 3.
  Introduction: What isChronon? • Chronon is a commercial Eclipse plugin (Chronon Systems) • 4 years of development • Left beta status on April 25, 2011 • Chronon does two things: – Recording a program execution – Debugging the recording 3 / 30
• 4.
  How do Icreate a recording? 1. Tell Chronon what classes and packages to record e.g.: – Include: com.mycompany.myproject.** (default) – Exclude: java.** (default, can not be removed) 2. Run the program ● The recording stops once the program is finished. ● No breakpoints! 4 / 30
• 5.
  How does therecording work? (1/4) • What is recorded? “every single line of code” [1] of the included packages/classes – Variables history – Method calls (arguments, return value) – Exceptions – Console output – Threads 5 / 30
• 6.
  How does therecording work? (2/4) • How does Chronon collect the data? – Chronon Recorder is attached to the JVM on startup as VM agent (JVM Tool Interface) ­javaagent:recorder­1.1.0.151.jar=config.txt     ­agentpath:librecorderagent64­1.0.0.so – Instruments included classes during load time – Logs events to disk • To disk? Isn't that kind of slow? 6 / 30
• 7.
  How does therecording work? (3/4) • How does Chronon try not to be slow? [2] – Idea: Taking advantage of the hardware • MultiCore (increasing number of cores) • Memory is cheap • Disks are getting faster (Solid State Drives – SDD) – Only collect minimal amount of data needed during recording – Minimal work inside application threads – Recorded data is stored in a buffer in memory – Flusher threads write buffer to disk in highly compressed file (gets unpacked for debugging) 7 / 30
• 8.
  How does therecording work? (4/4) Image Source: [2] 8 / 30
• 9.
  Comparison: "Practical Object-OrientedBack-In-Time Debugging”, Lienhard et al. (ObjectFlow Debugger) [3] • Short recap: What approach did the paper take? – Extends the VM: object references are represented as real objects (alias objects) on the heap – Alias objects keep track of the object flow and field history – Only keeps the history of those objects that are referenced in the current program state (using standard VM garbage collection) 9 / 30
• 10.
  Comparison: ObjectFlow Debugger– Chronon (1/2) ObjectFlow Debugger Chronon Only history of referenced objects Complete history History in memory History on disk “Live” debugging (breakpoints, modify Debugging on a recording (no variables/code) breakpoints) History up to a breakpoint History of whole program run Also tracks reading a field and adding Only tracks assignments objects to an array Deep modifications to the VM Runs with every JVM 10 / 30
• 11.
  Comparison: ObjectFlow Debugger– Chronon (2/2) ObjectFlow Debugger Chronon Focus on object flow Focus on control flow (time line) ●Where was this object used (as field, ● Which values did this variable have? argument, return value)? ● When was this method called? ●How was the object passed into this method? ●Which statement was executed after/before this statement? 11 / 30
• 12.
  Demonstration • Debugging mouse-events – Using the conventional debugger – Using Chronon • Debugging a multi-threaded application 12 / 30
• 13.
  Chronon Debugger • Timeline • Run to line/method (Forward/Backward in time) • Calls on the current line (arguments, return value) • Thrown exceptions • Variable history • Method history • Recorded console • Stacktrace • Threads 13 / 30
• 14.
  Performance-Evaluation • Two tests with open-source Java projects – Java SE application: Object database db4o [4] (database file on disk) – Java EE application: Google Refine [5] (“a tool for working with messy data”, ETL: Extract-Transform-Load), runs on Jetty application server • Micro-Benchmark 14 / 30
• 15.
  Performance: db4o • Test setup – Unit-Tests: com.db4o.db4ounit.common.btree.AllTests – Chronon Include-Filter: com.db4o.** – Quad core (4 x 2,5 GHz), 2 flusher threads • Results – Time • Without Recording: ~ 44 s • With Recording: ~ 130 s (factor: 3) – Recording size • Packed: 28 MB • Unpacked: 583 MB (time to unpack: ~ 30 min!) – Time “steps” (events): ~ 9.8 millions 15 / 30
• 16.
  Performance: Google Refine(Java EE) • Test setup – Chronon Include-Filter: com.google.refine.** – Test case: Sorting a table – Measured time to receive JSON response in Google Chrome Developer Tools • Results – Avg. time • Without Recording: 0.57 s • With Recording: 1.09 s (factor: 2) 16 / 30
• 17.
  Performance: Micro-Benchmark (1/2) package chronontests.micro;   public static class A {     private int a, b; public class Test {   private static int COUNT = 1000000;     public A(int a, int b) {       this.a = a;   public static void main(String[]        this.b = b;                                args) {     }     System.out.println("Start");     for (int i = 0; i < COUNT; i++) {     public int test() {       A obj = new A(i, i + 1);       return a + b;       //obj.test();     }       System.out.println(obj.test());   }     } }     System.out.println("End");   } 17 / 30
• 18.
  Performance: Micro-Benchmark (2/2) • Results (total time) – Without printing the result of “obj.test()” • Without Recording: 0.067 s • With Recording: 15.46 s (factor: 230!) – With printing the result of “obj.test()” • Without Recording: 15.5 s • With Recording: 26.4 s (factor: 1.7) 18 / 30
• 19.
  Using Chronon forJava EE applications • “57% of application performance spent in data access” (The State of J2EE Application Management: Analysis of 2003 Benchmark Survey, Ptak, Noel & Associates, 2003) • Typical Java EE applications spent a large amount of their execution time waiting on resources (databases, IO, network). → Chronon does not record new data during that time 19 / 30
• 20.
  Limitations (1/2) • Inspecting collections and other classes of external libraries (planned: “lightweight instrumentation” of classes, only record changes to fields) • Always records the whole program execution • Unpacking a recording takes its time 20 / 30
• 21.
  Limitations (2/2) • No automated dynamic slicing [6] – Slice: a subset of a program relevant for a given statement S • Forward slices: all statements influenced by S • Backward slices: all statements that influence S – Data/Control dependencies int main() {     int a, b, sum, mul; • Where does this value go to?     sum = 0;     mul = 1; • Where does this value come from?     a = read();     b = read(); • Why is this line of code executed?     while (a <= b) { • Why was this line of code not         sum = sum + a;         mul = mul * a; executed?         a = a + 1;     }     write(sum);     write(mul); Backward slice for write(mul) } 21 / 30
• 22.
  Advantages (1/4) • Helps narrowing down the defect which caused a failure – “Debugging is a search in space and time” [6] → Going backwards in time is extremely useful – Eliminates problems of breakpoint debuggers [7] • No “guessing” where to put the breakpoint • No “Whoops, I went too far.” Image Source: [6] 22 / 30
• 23.
  Advantages (2/4) • Gives direct answers to questions like … – When was this value set? – Who set this value? – When did this output happen? – When was this exception thrown? – Has this line of code been executed? – ... 23 / 30
• 24.
  Advantages (3/4) • Makes reproducing problems easier – Record the program in an environment where the problem occurs – Analyze the recording on a development system • Reproducing data / user interaction / communication / operating environments / schedules Replay Image Source: [6] 24 / 30
• 25.
  Advantages (4/4) • Helps debugging multi-threaded applications • Useful tool for code comprehension • Scales with the hardware • Highly compressed recording that can be exchanged between developers • Reasonable overhead while recording 25 / 30
• 26.
  Conclusion • Chronon is an useful tool that makes debugging easier • Analyzing the recording is already powerful, but still room for improvements 26 / 30
• 27.
  How can Igive it a try? • Chronon Systems: http://www.chrononsystems.com/ • Licenses – 30 day evaluation license – 1 year student license 27 / 30
• 28.
  Related Work /Software • IntelliTrace in Visual Studio 2010 Ultimate: C#, VB, ASP.NET, F# • Omniscient Debugging (ODB) for Java, Bill Lewis (last update: February 2007), similar to Chronon: http://lambdacs.com/debugger/debugger.html • Whyline for Java, Natural Programming Project, Carnegie Mellon University (US Patent in 2010, but not developed any further?), supports dynamic slicing: http://www.cs.cmu.edu/~NatProg/whyline-java.html • JSlicer – dynamic slicing tool for Java, Lehrstuhl für Softwaretechnik – Universität des Saarlandes: http://www.st.cs.uni-saarland.de/javaslicer/ 28 / 30
• 29.
  References / Links [1]Chronon: http://www.chrononsystems.com/ [2] Design and Architecture of the Chronon Recorder, Chronon Systems, 2010: http://eblog.chrononsystems.com/design-and-architecture-of-the-chronon-record-0#!/ [3] Practical Object-Oriented Back-in-Time Debugging, Adrian Lienhard, Tudor Gîrba and Oscar Nierstrasz, 2008 [4] Object database db4o: http://www.db4o.com/ [5] Google Refine: http://code.google.com/p/google-refine/ [6] Why programs fail – A guide to systematic debugging, Andreas Zeller, Second Edition, 2009 [7] Debugging Backwards in Time, Bill Lewis, 2003 29 / 30
• 30.
  Discussion Thanks for your attention! Any questions? 30 / 30