I've been a zone leader with DZone since 2008, and I'm crazy about community. Every day I get to work with the best that JavaScript, HTML5, Android and iOS has to offer, creating apps that truly make at difference, as principal front-end architect at Avego. James is a DZone Zone Leader and has posted 639 posts at DZone. You can read more from them at their website. View Full User Profile

Introducing Chronon: The Time Travelling Debugger for Java

  • submit to reddit

Last week I read an announcement about Chronon, a time travelling debugger. It sounds very appealling - if you're like me, you've often missed that spot where you should have had a breakpoint. Another common issue is reproducing bugs that happened out in the field. Could this tool be the solution to all your problems? I spoke with Prashant Deva, founder and CEO of Chronon, to find out more.

DZone: Could you introduce Chronon?

Prashant: Chronon is a revolutionary new technology that consists of:

  • A 'flight data recorder' for Java programs which can record every line of code executed inside a program and save it to a file on the disk. The file can be shared among developers and played back in our special time travelling debugger to instantly find the root cause of an issue. This also means that no bugs ever need to be reproduced!
  • A Time Travelling Debugger, with a novel UI that plugs seamlessly into Eclipse, which allows you to playback the recordings. It not only step back and forward but to any point in the execution of your program.

Chronon marks the begining of the end of 'Non-Reproducible bugs'.  A Chronon recording can be shared among all the members of your team and they can debug an issue in parallel. We see Chronon being used all the way from Development, QA to ultimately running full time in Production.

DZone: Has anyone tried to solve this before? How far did they get?

Prashant: There has hardly been any actual real world effort which has come anywhere close to Chronon.
The only research we could find was some papers in the academia and even that was pretty useless to us. The methods described in those papers were too slow to record real-world programs.

The fact that it has taken us over 3 years of sleepless nights and days goes to show the kind of effort that is required to pull off something like this.

As far the time travelling debugger goes, the only ideas we could find were having a 'step back' button, however if you see the demo video of Chronon on our website you will notice that although we do have a step back button, the mechanisms we provide in the debugger make the whole concept of stepping 'redundant'. Once we found that we have literally collected all the runtime data of a program, we thought we could do a lot more than just stepping forward and backward. So if you look at the video you will realize that what we have done is literally reinvented the debugger. For example, if you have a loop from 1 to 10 that uses the variable 'i', you can click on that variable inside Chronon and it will show you all the values ever assigned to it (from 1 to 10 in this case) and clicking on any value say '5' would jump to the point in time when '5' was assigned to 'i'. This is just a small example of the many, many innovations we have got. The demo video on our site does a good job of demonstrating them.

DZone: Will this have full integration with any IDEs?

Prashant: We have the highest possible level of integration with Eclipse right now. Chronon blends seemlessly with eclipse and becomes a part of it so you can start using Chronon in literally seconds with no prior knowledge of it

DZone: How is this implemented?

Prashant: To use Chronon manually (from outside the IDE, that is) you just need to add an extra argument to the command line which specifies the location of our java agent.

Chronon works by instrumenting the classes loaded in memory so you dont need to modify any source code to use it.
We record only the code that is the part of your program. The code you didnt write you cannot debug anyway.
Thus for example, if your program runs on tomcat and uses a bunch of 3rd party libraries, you dont want to record those cause even if there is a bug in them you cannot debug it. For all the calls to non-recorded methods, we record only the input and output from it.

So in the case of a call like 'byte[] b = readFile(fileName)', we will record the 'filename' and the returned byte array and that is what you care about anyway when debugging. You dont care about how the os/kernel actually reads the file in cause you never wrote that code. This way you can also really control the performance impact the recorder has on your program.

During the actual recording, Chronon will collect data at meaningful events in the execution of the program. It will try to shift as much of its work to other spare cores thus trying its best to leave the threads/cores being used by your program as untouched as possible. The other cores will do minor processing on the data and then compress it and save it to disk. Before you can debug, a separate program will 'unpack' the compressed recording data and expand and index it so it can be quickly queried by the debugger. The 'unpack' process will obviously run after the program has finished execution and can be run on a completely different machine.
Thus when you are 'playing back' the recording you are actually reading data from a file and not re-executing any code. So if your program deleted a bunch of files, you can rest assured that its not going to do that again.

DZone: Does it cause any performance issues? Will my app run slower when using this?

Prashant: Our aim with this release is just to make sure that a person using a program with recording enabled cannot distinguish from a program without any recording and so far we are on track with that.

Performance is something that has been a prime concern for us when developing Chronon and we have gone through a lot of hoops to ensure maximum performance.  We try to shift our workload across multiple cores to not disturb your program as much as possible. We try to minimize our use of the JVMTI apis which one would think is what you would use for such a thing, but we found it to be too slow for our purposes.
Since the performance impact is really directly proportional to the amount of execution recorded. You can even control the performance by specifying exactly what is/what isnt recorded. That said we want to see as much code being recorded as possible.

The performance impact depends on how much execution time is being spent in the code being recorded. If your code makes a lot of calls to a database or spends its time within a lot of 3rd party libraries, something that is true for most j2ee apps out there, you wont notice any performance impact at all.

Our position on performance is that we dont give out raw benchmark numbers since they can be so easily manipulated. You should run your real world program on Chronon and see how it performs.

Also we are improving the performance of Chronon constantly. The performance of Chronon today is better than what it was 6 months from now and its going to be keep getting better and better.

So far we have found that  Java with Chronon recording performs way, way better than if the same code was written in python, ruby, php, etc. So if you are comfortable writing for those platforms you shouldnt have any trouble with Chronon.

To find out more, view the embedded Google Tech Talk: 

Chronon will be available as a commercial product later this year.


Ron Pressler replied on Tue, 2010/07/13 - 5:09am

Looks cool, but the concept isn't really new. Bil Lewis's Omniscient Debugger has existed and been usable for quite some time now, although it only records to memory. Another such debugger is TOD which records to disk, is said to be scalable for very large programs, and is also integrated with Eclipse. In fact, Bil Lewis used to refer to his debugger as a "silver bullet" as well. Here's his tech-talk at Google called "Debugging Backwards in Time".

Marc Stock replied on Tue, 2010/07/13 - 1:22pm

Let me know when there's IntelliJ support. Love the idea but until then it's of no value to me.

cowwoc replied on Tue, 2010/07/13 - 11:48pm

Agreed. There is no way they should get a patent for this. Bil Lewis implemented this years before they did.

Dean Schulze replied on Wed, 2010/07/14 - 2:44pm

One of the most difficult problems to solve is deadlock since you can't usually reproduce them.  There is no mention in the article of using Chronon to solve threading issues.  Have you used Chronon to solve previously unsolveable deadlock bugs?  Chronon sounds like exaclty what you would want to solve thread problems.



Prashant Deva replied on Wed, 2010/07/14 - 6:28pm in response to: Dean Schulze

Yes multithreaded programs are definitely a big focus for Chronon. The website will have many examples of how to diagnose concurrency and deadlock issues as we get closer to release.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.