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.
We have updated Chronon with some bugfixes related to recording JEE servers from within Eclipse.
If you were seeing an exception when trying to Record a server, you shouldnt see it anymore.
Everyone please update using the update instructions here.
4 years ago, when I was still in college, every time I would encounter a bug in my program it would be a nightmare. Debugging would involve many, many hours of trying to reproduce the bug and fiddling with breakpoints. Of course, we all know how tough it is to reproduce a bug when it occurs in production, but even while developing it can be a nightmare when you have to go through a whole series of steps that takes a full 5 minutes before you can run your program to point where it hits the breakpoint where you think the problem might be. Of course like everyone else on the planet, I would never, ever get that breakpoint right the first time. Thus would begin my frustrating journey as I would keep fiddling with my breakpoints trying to get it to break the exact moment before the error occurred. And of course most of the time I would end up stepping over that the error nous piece of code and end up cringing, if only I could step back! And god forbid, if that error was in a multithreaded program I really wanted to step back because I may never be able to reproduce the error ever again.
If only I could step back....
With the release of full version of Chronon today, I think its safe to say this marks the beginning of a new era for Java and programming in general. No longer is the thought of debugging scary. No longer do we have to worry about reproducing bugs. No longer do we have to wish if only we could step back. We can.
What initially began few years ago as an idea for a debugger with a 'step back' button has morphed into something much greater. We now have a full 'flight data recorder' for Java, which can produce recordings to disk, eliminating the need to reproduce bugs entirely. When we started working with the data from the recording, we realized we can make something much bigger than just a 'step back' button. The result is all the amazing functionality that the Chronon debugger provides. In fact, once you start using it you realize that you rarely ever need to use any of the stepping buttons at all!
We really do want every Java developer using Chronon technology to record and debug their applications, thus ending the nightmare of debugging entirely. To that end, instead of pricing Chronon at a super-expensive price where the only way to buy it would be to get approval from 5 layers of management and involve tons of sales people, we have decided to make it so affordable, you dont have to think twice about purchasing.
Currently our most expensive plan costs only $35/month (price of a good dinner) and it goes down to just $10/month (price of a movie ticket). We have also decided to offer the product as a subscription. This is another way to keep our prices down since we dont have to charge you a large fee for a perpetual license. Also this means we dont have to stall bugfixes and upgrades to entice you to buy the next version. As long as you have an active subscription you can download all the updates for free.
A big part of this release is the new Eclipse Java EE integration. You can now record your Tomcat/JBoss/any other app server right from within Eclipse. Below are some of the screenshots of the functionality:
We have even published a video demoing the Chronon integration with Eclipse Java EE. You can even read about the integration features here.
Thanks to the feedback of a huge number of beta testers, we have been able to fix an enormous amount of bugs and improve the product a lot. If you used a beta release, you should definitely try the current release and you will have an entirely different, much smoother experience. I will be describing in technical detail some of the improvements in the next few blog posts.
That said, we have a lot more in store. If you think the current Chronon is cool, wait till you see what we come up with in the next few versions. We will keep improving the product very frequently in the weeks to come. With our subscription model, you should be getting them as soon as they are available. So go ahead, download Chronon and give it a try with the free 30 day evaluation.
We have published a Chronon Performance Guide to help people understand and tune the various components of their system and chronon to gain the maximum performance. Of course we will keep updating this as we update Chronon.
Performance tip number 1 : Use 64 bit!
Since we are running a few days behind on our release schedule, I updated the beta build with one that expires on April 21.
This update contains a ton of bugfixes. Stack view is much faster now, and shouldnt lag when there are lots of threads at a point in time.
Also errors related to 'method too large' to instrument are now gone. We just skip over and exclude methods that are too large.
I advice everyone to upgrade.
We have recently published a Chronon Internals Guide where we have organized and linked to the blog posts here which describe how Chronon works.
We will keep updating the guide as we add more blog posts here.
A lot of times I write code that is supposed to do lazy loading. However it is tough to actually verify if in fact the lazy loading is taking place or did my code just load the entire set of data instead. With traditional debugging tools it would take a bunch of println() statements, a new build, and probably the entire lunch hour to verify the lazy loading behavior.
Note that in this case I am not 'debugging' in the traditional sense. I just want to verify whether my code is behaving at runtime how I want it to.
With Chronon, its instant. Just run your code and look at how it behaved in the time travelling debugger. No println() statements, new builds or anything special required.
We have made a video demonstrating this for a sample tree viewer with a lazy content provider.
You can also watch more videos demonstrating the use of Chronon to solve real world issues.
The Chronon beta launch has blown past our wildest expectations!
We got on the front page of :
- Hacker News
- Reddit - Programming
We were talked about in the Java Posse podcast.
We joined the Eclipse Foundation.
We couldn’t have developed Chronon without the maturity of the Eclipse platform, as we are excited to officially join as a member.
We won the first ever EclipseCon new products Showcase!
Chronon won the first "Eclipse Hot New Products Showcase", held during EclipseCon 2011. The new product showcase award is given to the hottest Eclipse-based product, as voted by EclipseCon attendees, built or released in the last year. It was humbling to see the community support for Chronon, as we faced 20 other, much bigger competitors.
I remember talking to my business partner before the beta launch and since we didnt have much of a budget for marketing, we thought if we could get just 100 users for the beta, for a till then unknown product, we would consider it a success. Of course we shot way, way past that number within hours! In <12 hours of the launch we were on the front page of reddit and hacker news. I personally was on a flight to India during this and on my stop at Dubai to catch the connecting flight, I remember opening up my laptop and seeing all this crazy traffic on our website, bringing our server to its knees. I remember frantically calling one of my partners from the airport, on international roaming, to immediately upgrade the server. Overnight success feels awesome, especially if you have been working on it for over 4 years.
Since then we have been updating and polishing the beta based on the immense feedback we have gotten. We have also been updating and maintaining our documentation as we go along. Although we are not an open-source product, we like to be completely transparent on what is going on behind the scenes in Chronon. We believe that is more useful than just dumping a pile of source code which few would bother to read. For that purpose we have been updating this blog with the technical details and design decisions of Chronon and will continue to do so.
We are now just days away from the full release of Chronon. If you still havent tried Chronon, please download it from here.
I will end this post with just a few of the tweets from our users:
Yet another update posted for Chronon with some more bug fixes and polish.The expiry date is now April 10.
This will also be be the final beta before the full 1.0 release.
We have posted another update to the beta.
This release contains minor bugfixes and of course, some of the features we talked about previously.
More importantly we have increased the expiry date to April 1.