Return back to the blog

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.