Already considered as quite an impressive tool, Chronon 3  was released recently, bringing even more features and improvements.  Top of the list are the performance improvements; and the improvements delivered cannot be understated. You won't need to worry about running out of memory with Chronon anymore.

I asked Prashant Deva, Chronon's founder, about how exactly they got the improvements. Because of the amount of feedback the team were getting about OutOfMemory errors, Chronon 3 was completely re-architected from the ground up. Obviously, this process took a lot of time, and is the reason there was a long time between the previous release and Chronon 3.

Prashant gave me an amazing insight into how Chronon recorder works in the background:

If you were to look at the source code of a computer program, especially a single threaded program, you will notice that you can pretty much predict what a program is going to do.  Sure the program will have branches and loops but those brances will be dependent on the values of some object in memory and if you know its value, then you can predict the flow.

Chronon 3 Recorder is based entirely on this idea of 'predictions'. The Recorder reads the bytecode of your application and does a static analysis of your code.
From this analysis, it creates a bunch of 'predictions', about how your program will execute.
An example of a prediction might be :
Call bar() at line 46 in Foo.java.
Then it monitors the execution of your program.
It keeps adjusting the 'prediction' data structures to account for what your program acutally does.
Then the recording data that is generated is really just how much your program differs from these predictions.

For example, in the case of the earlier prediction:
Lets say you have 2 threads:
Thread 1 :  
Execution matches prediction completely
Calls Foo.bar() at line 46 in Foo.java.
In this case, no recording data is generated, since the prediction is matched 100%.

Thread 2
Calls overloaded method Foo2.bar() at line 46 in Foo.java.
In this case, the prediction data here will be modified, for this thread only, to account for the fact that 2 methods may be called here - Foo.bar() and Foo2.bar()
Then only 1 bit, is saved which tells that Foo2.bar() is the method that was acutally called.

In previous versions of Chronon these method calls would have generated over 128 bits of data per call. In Chronon 3, they generated 1 bit or no data at all.
Thus you can get a glimpse of what a huge performance benefit this is.

The other thing we have done is to make use of non-heap memory as much as possible. So most of the recording data, and things like compression, etc are all done natively and dont impact the heap of your java application and thus dont impact the GC.

Another new feature you'll want to try out is  Per Thread Time , allowing you you to focus on specific thread instead of the entire system. You get to see this in the Stack view too. Focus is everything - if you know of a troublesome thread, you can forget about the rest. 

Also you can split recordings at any time on the server, instead of waiting for the Recording Server to split them for you.

Chronon have offered JavaLobby readers a special 10% discount to use when purchasing personal licences of Chronon, using the JAVALOBBY coupon code

In the future, you can expect closer releases of Chronon, where the prediciton plug-in model will be continuously added to. The more predictions that Chronon provide will improve the performance.

As always, Chronon are listening to what users want in order to define the feature set for the next release. You can expect to see support for Java Collections sometime soon, another much requested feature, while the Recording Server will have new features to help with Ops and Application Monitoring.