Beta update 4

Posted by Prashant Deva on April 15, 2011

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.

Chronon Internals Guide

Posted by Prashant Deva on April 11, 2011

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.  

Verifying Lazy Loading behavior of code

Posted by Prashant Deva on April 7, 2011

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.

Chronon Systems – Beta Report Card

Posted by Prashant Deva on April 5, 2011

The Chronon beta launch has blown past our wildest expectations!

We got on the front page of :

  • Hacker News
  • Reddit – Programming
  • Javalobby
  • EclipseZone
  • TheServerSide

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.

The backstory:

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:

Tweet3
Tweet1
Tweet5
Tweet4
Tweet2

Beta update 3

Posted by Prashant Deva on March 31, 2011

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. 

Step to super()

Posted by Prashant Deva on March 21, 2011

Consider the following  piece of code:

class B extends A {  //constructor  B()  {        this.field1 = "asdf";  }}void foo(){   B b =  new B();}

Note that the constructor of class B does not contain an explicit call to super()

In a traditional debugger, if you put a breakpoint on the line

B b = new B();

and ‘stepped into’ the call to new B(), you would be taken directly inside B(), with no chance to look at the super constructor of class A. The only way out of this would be to

  1. Go back and explicitly place a breakpoint inside A()
  2. Reproduce the bug (if it is at all possible at this point).
  3. Start debugging all over again….
  4. … only to have this happen again accidentally for the constructor of another class.

Step to Super

Step-super

To deal with the issue of an explicit call to super() not being present, in Chronon we added a ‘Step to Super‘ button in the Stack view.
This button is active only when you are inside a constructor and clicking it takes you directly to the constructor of the superclass of that method.

Step-super-1Step-super-2

The screenshots above show this in action.

Debugging with Excluded Code: Locals View

Posted by Prashant Deva on March 20, 2011

A big design challenge when creating the Chronon debugger was that we allow people to arbitrarily exclude code from being recorded. Although this allows for increased performance, it means we lose out on that data which then cannot be displayed in the debugger. With this in mind, every portion of the debugger was designed to gracefully handle the fact that some data can be missing and to still show as much useful information as possible to the user. In this and the subsequent series of blog posts we will discuss about each portion of the debugger and how it handles excluded code.

Locals View

Locals-overview

 

The locals view is probably the noticeable part and the one we expected to hear most complaints about even before we launched the beta.
Excluding a class means that any object you create of that class will not have its fields recorded. So in that case, the Locals view will only be able to show you the ‘type’ of that object. This is most visible in the case of collection classes like ArrayList, HashMap, etc because you cant see the elements they contain. Note, that contrary to what some people might think because of this, you *can* browse the full hierarchy and contents of objects that have classes included in recording.

We thought and experimented this quite a bit before doing the release and here are some conclusions we came up with:

  1. If a Collection class contains more than 10-20 elements, the ability to see its contents dont matter much during debugging anyway since that starts becoming ‘too many’ to comprehend manually.
    Locals-largearraylist

     

  2. If you have a piece of code takes a Collection and iterates over it in a loop, you can see the variable history of the loop variable and see all the elements inside a Collection that way.
    Locals-varhistory

     

  3. Since unlike a traditional debugger, there is no ‘cost’ of stepping, you can always jump back in time in your code and see exactly what was assigned/removed to the Collection.
    We even have a video which demonstrates debugging a real world bug this way.
  4. As for other non-collection objects, we realized that most of the time the reason why we excluded their classes in the first place is because we want to treat them like black boxes. These are usually much less of a concern than the collection classes.

All that said, we do realize that having more data is useful and it would indeed be better to be able to expand and look inside the fields of as many objects as possible. Some stuff we have planned for future releases to address this:

  1. Lightweight instrumentation
    This would allow us to only record changes to the fields of the classes and skipping over all the other code executed inside the methods.
    Perfect for collection classes or classes like java.io.File where its good to see the fields of the objects but you dont care to step inside its methods.
  2. High performance
    Plain raw performance increase in the recorder will just allow you to record more without sacrificing performance of your application.
  3. Smaller recordings
    Same as above. Decrease in the size of recordings generated will also allow recording more data.

Upcoming feature: Pattern Cheatsheet

Posted by Prashant Deva on March 9, 2011

Its always a pain when you see a dialog which prompts you to enter patterns, because if you are like me, you dont remember what the patterns are and then you have to go look at a manual, and nobody like reading manuals anyway.

Nopatternbutton

So for our upcoming build of Chronon, we put in a little ‘Pattern CheatSheet’ button at every place in the UI where you need to enter include/exclude patterns.

Patternbutton

Clicking on the button shows you a nice little dialog with the available patterns.

 

Cheatsheet

No need to look at manuals :)

« Previous 1 2 3 4 5 6 7 8 9 10 11 Next »