We have updated the Chronon Eclipse plugin to support the Google GWT plugin. You need GWT plugin version 2.4.2 or higher for the Chronon plugin to be enabled for it.

With the GWT support:

• You can record GWT applications easily in development mode.

• The GWT 'Development mode' view has the Chronon 'blue' stop button that is enabled when you are recording a GWT application. Make sure to use that instead of the 'red' button to stop your GWT applications, otherwise the recording wont be saved properly.

 

 

There seem to be some misconceptions regarding the Java Heap size arguments.

For those who don't know, Java is peculiar in the sense that you have to specify the amount of memory you want your program to use, before you run your program. If you fail to do so then depending on the version and implementation of the JVM, your program will only be allowed to use a fraction of your computer's total RAM. This is the reason why you might get an OutOfMemoryError even if your machine has 24gb of ram and you know your Java program needs way below that amount of memory.

The way to mitigate this is to set the -Xms and -Xmx parameters when launching your Java program to explicitly set the initial and maximum amount of memory your Java program is allowed to use.

Note the use of the word 'allowed' in my previous statement. This is the misconception I am talking about.  Let's say you start Eclipse with a setting of -Xmx6g. This does not mean that magically eclipse will start allocating more memory. All this means is that you have allowed eclipse to use 6gb of memory and that if a situation does occur that eclipse maybe for a short time needs that extra amount of memory, it will be able to use it and wont crash by giving you an OutOfMemoryError.

The need to pre define the amount of memory usage allowed was a big problem with Chronon , since Chronon does make good use of the memory on your system and gets a huge performance boost the more memory you give it. However since eclipse by default only sets a -Xmx value of 384m, we would get a lot of complaints from people saying 'I have 4 gigs of ram on my machine, why is Chronon still running dog slow'. And it would always involve setting the -Xmx and -Xms to a higher value.

So we decided to use some of the functionalities of Eclipse p2 and now when you install the Chronon Time Travelling Debugger eclipse plugin, we automatically increase the -Xms and -Xmx to a much higher value in your eclipse.ini file. This has obviously put an end to all the performance complaints and I bet has solved a lot of non Chronon related performance problems for some eclipse users who are now actually able to use their machines to their full potential when running eclipse.

Of course, this has angered some people who when they see the heap size in their eclipse status bar set to a high value tend to freak out. "What, my eclipse is suddenly taking more memory!". Thus, the point of this post is to make it clear that Eclipse is not magically using more memory when you install Chronon, you are only allowing it to use all the memory of your system which you paid with your hard earned cash.

In my last post I talked about 'flusher threads' which constantly 'flush' the recorded data from the memory buffer and persist it to disk.

However, due to the latencies in IO between memory and hard disk, it is entirely possible that your program terminates while there is still some data left in the memory buffer which hasn't been persisted.

To solve this issue, we register a 'shutdown hook' with the jvm which essentially keeps your program alive for a little while even after it terminates, so that we can persist all the leftover data. That is why you may see messages like these  on your console when your program shuts down when its running with Chronon.

However using the shutdown hook opens a whole can of worms of its own.

Since the jvm does not impose any sort of ordering of how shutdown hooks are run, we essentially 'stop' recording at this point. Thus if you have any custom shutdown hooks of your own, those will not be recorded.

There are also issues where the shutdown hook does not run, in which case the recording would be considered corrupt.

Some of the cases when the shutdown hook will run are :

• Program finishes execution normally.
• Program calls System.exit().
• Ctrl+C is used to kill the program.
• An uncaught exception terminates the program.
• The unix 'kill' command is used to terminate the program.

Cases when the shutdown hook does not run, thus leaving the recording in an invalid state :

• Program calls Runtime.halt().
• Unix command 'kill -9' is used to terminate the program.
• The 'End Process' option of the Windows Task Manager is used to terminate the program.
• Internal JVM crashes or crashes inside the native code.
• Any other program which sends a SIGKILL signal on an Unix machine or the TerminateProcess call on a Windows machine.

That said, most of our used will be using eclipse to launch and terminate their programs, so I really focused on making that use case always produce a valid recording.

Eclipse by itself unfortunately doesn't seem to be of any help in this case since the default red 'terminate' button sends a SIGKILL signal thus terminating the JVM instantly without waiting for any shutdown hooks to run. Thus if you use the 'red' button to terminate your programs running with Chronon, the recording will always be invalid.

So I went ahead and added a 'blue' button next to the 'red' terminate button.

Pushing the 'blue' button will make sure the shutdown hook runs and you always get a valid recording. The blue button is active only when a program is running with Chronon enabled and it is what you should always use to stop your programs from within Eclipse.

You can still use the 'red' button when say you were just experimenting with something and no bugs appeared or for some other reason you just don't care about the recording, but we recommend making the blue button your default for stopping programs from now on.