Introducing Chronon: The Time Travelling Debugger for Java

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.