“… Okay, let’s just set a breakpoint there … run again … continue continue continue next next next *argh* run again … continue continue continue next next … Why is it still null?? Who changes this field? Oh, damn … breakpoint … run again … where is that coming from? … oh no …”
Sound familiar? How often do you rerun your code just because you can’t step backwards in time? How often did you ask yourself “who is calling this method?” Or “where did this value come from?”
Meet Chronon. In a nutshell, Chronon runs your code, saves all state changes (method calls, variable assignments) somewhere and allows you to browse the result.
So with this tool, the text above would have been: “… Okay, it’s null here. Where does that value come from? *click* Oh, ok. Who called this method? *click* Oh, I see.”
This makes you find the source of an error much more quickly. Other questions that Chronon can answer:
- Find all instances of a class that were created. A special window lists all exceptions that were thrown.
- Step backwards (just like stepping forward)
- Go to the code that printed a certain output on the Console (just click on the output in the Console window!)
- Show me all the values of some variable (Post Execution Logging)
The tool is surprisingly fast. You’d expect something like that to hog your computer but collecting the data is pretty quick (just a small increase in the time it takes to execute the code; I didn’t time it).
It does take a mental leap, though. Stop thinking like you were executing the code. It’s more a specialized database browser where the data is all the states of your application.
Things that I don’t like:
- Opening a recording takes a few moments (<< 1 minute) while it “decompresses” the recording. I’m not sure what happens here. It seems stupid to compress the latest recording because chances are that you probably want to use it soon. But I guess this stage creates a couple of indexes so the UI can quickly navigate the data, so it’s just an unhappy label.
- The plug-in messes with my eclipse.ini! Bad plug-in, down! I understand that Chronon needs lots of RAM. And I think it does take your total memory into account (it allocated 2.5GB of my 8GB). Still, it should ask before doing something like that. And it absolutely should not do it again, after I reset the values to something sane. GCing 2.5GB of RAM does take a long time!
Dark Views 
Regarding the 2 points mentioned:
1. Recording Decompression (we officially call it ‘unpacking’).
First off, the unpacking (decompression) takes place only once, so the next time you open the same recording, it will open instantly.
Now for the question of why do we do this in the first place:
Well apparently when you are running your program with the recorder, the only thing we care about is to get rid of the generated recording data as fast as possible, so the recorder just compresses it and saves it to disk in a very unstructured fashion.
However, that compressed, unstructured format is not sufficient for the Chronon time travelling to be able to do what it does. So the ‘unpack’ phase does the decompression and even indexing of the data which the debugger can then query real fast.
If we didn’t do the compression while recording and did the indexing while recording itself, not only will it add huge overhead to the program being recorded, it will also significantly increase the memory requirements for the program, since now you wont be able to flush out memory as fast but new data will still keep getting generated in memory. Even if you closed the program, Chronon will have keep the jvm from shutting down completely until it indexed all the data.
So the total time taken for you to open the recording in the debugger from the time you opened the program would be the same, just that you will add enormous overhead to the original program which may render it unresponsive
Also in the case that the program you just recorded, didnt contain any issues you want to look at, you just wasted more disk space and more time.
Thus the ‘unpack’ phase was chosen as it provides a good middle ground. You get good performance while recording and also while playing back in the debugger, but you just have the one time penalty of unpacking.
2. As for eclispe.ini. First off as you yourself mentioned, we are very careful about modifying it. For 32 bit machines, we set the -Xmx value to 900m and for 64 bit to 2.5gb. Also if you eclipse.ini already has a higher -Xmx value, it wont be modified at all. The reason we dont put up a yes/no box is well apart from the fact that the standard eclipse plugin installation doesnt allow it, there is no ‘no’. If you dont allow eclipse to use that much memory, Chronon simply wont be able to function.
Note that this is also done by the popular ‘Findbugs’ eclispe plugin which sets the eclipse.ini -Xmx value to 900m.
Also note that we are modifying the -Xmx value not the -Xms value, so its not like eclipse will magically start allocating more memory. All -Xmx does is say ‘if i *need* this memory, please allow me to use it, without throwing an out of memory exception’
More details about this on our blog:
http://eblog.chrononsystems.com/misconceptions-regarding-java-heap-size-argum