After committing, at first you use the following command to figure out the hash of the commit that you would like to revert (usually the commit before your faulty commit):

Now you use the following command with the hash in sharpen brackets to revert to the previous commit:

After this procedure the faulty commit is not recognized anymore by your Git repository and you can continue working on your project.

The following code snippet shows the application of this feature. Callers can pass only classes that implement the interface IMessage. In the method body we can refer to methods of this interface.

Components
The architecture of the debugger generally consists of two components: a recorder that is responsible for collecting and storing the execution and program state; and a frontend that is integrated into the Eclipde Debugger UI. The frontend reads the recordings to realize the debug behavior.

Frontend
As mentioned in the previous paragraph, the frontend is integrated into the Eclipse IDE, actually in the Debugger perspective. Chronon provides a tutorial on how to migrate IntelliJ projects to Eclipse, in order to use their debugger, but a real IntelliJ integration is currently not provided.

Just like with other Java debuggers, users can debug their programs with the well known step-through metaphor and view the values of local variables and arguments. The debugger shows the variables for the current context and their corresponding values in a separate window. Beside watching the values of variables for the current context, users can also inspect the value history of variables and continue debugging with the state that the program had at the time of a specific value assignment (that is cool!). The following figure shows the related UI elements: the variables view in the upper left corner, the editor view in the lower right corner and the variables history in the lower left corner.

In the previous paragraph we have seen the variable history which allows users to step through different program states of the debugged program. The debugger also provides the well known stepping commands, such as step over or step into, but it also allows users to step backwards (step back). With this feature users can do and undo assignments or other changes to the program or execution state on the level of statements. The following figure shows the call stack and the command bar with the debug operations.

Recorder
In the previous section we have seen the features provided by the debugger and its UI-integration in Eclipse. We will now talk about the backend component which is responsible for collecting and storing the trace/debug data from the running Java program. The following figure shows the involved components and the data flow between them:

The shown components have the following responsibilities:

• Application threads store debug data in the memory buffer (RAM).
• Flusher Threads read the data, do processing on it and save it to disk (Recordings).

While studying the architecture I started wondering how the garbage collector performs with debugged applications. From my point of view this might be the bottleneck, but it seems like Chronon solved this problem:
“It is a well known fact that current JVMs don’t handle heap sizes above 2gb very well. It is possible that if you have an extremely computationally intensive program that Chronon does generate utilize that much memory or that your application already is reaching the 2gb limit and Chronon makes it go over that. To solve this issue we use a custom memory management. Thus even if the data generated by Chronon goes a little high, it wont have a heavy impact on the GC. It is common to see a 2-3gb Chronon heap shrink to a few hundred megabytes within a blink of an eye, which would ordinarily take many seconds or minutes without our custom memory management.”

Requirements
Chronon designed the bakcend based on the following non-functional requirements:

• Scalability
• Minimum impact on application responsiveness
• Libraray and Framework Independence

The first requirement deals with vertical scaling across multiple CPU cores. The figure shows this by multiple flusher threads. The second requirement deals with the altered performance of the debugged appllication. The debugger instruments the bytecode at runtime to gain the tracing/debug data while the program is executed. The third requirement is related to different frameworks and libraries, such as JEE, SWT or SWING. The debugger provides debugging support, independent of the Java technology the application is based on.

Summary
In this article I have shown the features of the Chronon Time Travelling Debugger, how it is integrated into the Eclipse Debugger perspective, the design of its backend component and finally its non-functional requirements.

After asking Google without success I started searching for the key, listed in the message, on my file system. It seems my known_hosts file, locaed in the ~/.ssh/ folder, had an error in one of the listed lines: there were two entries (with the key listed above) in a single row. After deleting the line, the error message disapeared.

Problem fixed!

The speaker describes at first the context in which debuggers were designed from late 70′s till today:

• Programs are single threaded
• Execution flow is sequential
• Bugs are always reproducible
• Programs run for short periods of time

Then he talks about the requirements on debuggers in 2011 and problems they face today:

• Multithreading
• Flow of execution not 100% sequential
• Reproducing bugs is (very) tough
• Programs run for weeks/months/years

I agree on the first two arguments, although I would summarize both under multithreading, since multithreaded programs are already less than 100% sequential. The third statement is from my point of view dependent on the actual project (technologies and infrastructure). The final point is not specific for 2011 (today). Back in the days, developers also wrote programs with millions loc. Additionally to the mentioned requirements, I would add the following two:

• Distribution across multiple machines
• Development with different languages

The first requirement addresses applications that are distributed across multiple machines. Many debuggers allow remote debugging, but this is not the point here. What I want as a developer is a unified debugging view on my system. I should be able to step into (of course also step out, over etc.) a web-service on machine B from machine A. The tool should handle the the execution flow and update the UI accordingly. The other requirement deals with multi-language systems, developed with multiple languages. Not only with the rise of JVM languages are systems developed with multiple languages. Back in the days, Java EE developers used already multiple languages, such as Java and JSPs (both as a language), to develop their systems. Here, as a developer, I want a unified debugger which abstract from the process barriers and allows me to debug the whole system in the same context.

Vraný et al. describe in their paper an architecture for integrating multiple heterogenous debugger in a common UI. With their system, users can revisit the execution flow and control it. This is a good starting point for tackling the mentioned requirements, but not yet the last word on the subject.

In my next post I will provide an overview of the presented debugger prototype, which provides already the time-travelling feature.

With Git, you can simply store your changes locally and pull the latest commit from the remote repository. After pulling, you can work directly on the pulled commit or you can merge you previously saved changes and continue working on them.

The following snippet shows the commands for storing your changes locally and merging them into the head after pulling new changes: