Chipping software for faster debugging
If you've spent some time doing software development, you know that debugging and testing consume more time than writing code, especially on large projects. And when your product is finally released and a user discovers a bug, it can be very difficult to isolate the cause of the bug. In a very short news release, UC Davis says that two of its researchers can ease developers' lives with their software 'chipper' which breaks a big piece of software into smaller ones. I'm not sure if this approach can work for very large software projects. However, the computer scientists have developed ChipperJ, a version developed for Java. And they claim that ChipperJ was able to reduce large programs to 20 to 35 percent of their former size in under an hour.
You can see above a screenshot of v-diff in action, a tool developed by the researchers to analyze the variants of an original program generated by ClipperJ. When they produce a variant, they want to execute it to see whether it provides the same result as the original code to determine if the variant is good or bad. "The right panel contains a scrollable, clickable canvas that shows the good variants (light shading) and bad variants (dark shading). The variants are identified by their variant number. The top left panel is a scrollbox with a list of all of the variants for a particular run of the chipper. Below that scrollbox is a control panel with two textboxes. They can be filled with the names of variants selected either from the scrollbox or from the scrollable canvas. Doing this allows the user to directly compare two variants. (Credit: UC Davis)
The ClipperJ program is the brainchild of Ron Olsson, professor of computer science, and one of his graduate students, Chad Sterling, now working for Hewlett-Packard in San Diego.
If you are interested by this 'chipper' software, this research work has been published in Software: Practice and Experience under the name "Automated bug isolation via program chipping" (Volume 37, Issue 10, Pages 1061-1086, August 2007). Here are two links to the abstract and to the full text (PDF format, 50 pages, 585 KB), from which the above picture has been extracted.
Here is the text of the abstract. "This paper introduces program chipping, a simple yet effective technique to isolate bugs. This technique automatically removes or chips away parts of a program so that the part that contributes to some symptomatic output becomes more apparent to the user. Program chipping is similar in spirit to traditional program slicing and debugging techniques, but chipping uses very simple techniques based on the syntactic structure of the program. We have developed a chipping tool for Java programs, called ChipperJ, and have run it on a variety of small to large programs, including a Java compiler, looking for various symptoms. The results are promising. The reduced program is generally about 20-35% of the size of the original. ChipperJ takes less than an hour on large programs to perform this reduction; even if it took overnight, that would be reasonable if it saves the developer time."
And here are some of the conclusions of the two authors. "Our experience described in this paper represents a first step in program chipping and suggests much future work. We plan to develop further simplifications for the current ChipperJ, e.g., for expressions, method invocation, and eliminating entire methods or classes. We also plan to further investigate the efficacy of some of our present techniques, such as rechipping, and consider additional techniques to speed up chipping, such as using multiple threads to detect early in a variant's execution whether the variant is good (which would then allow a potentially long-running variant to be killed off sooner). We believe program chipping will work equally well for non-object-oriented code and we hope to develop a ChipperC for C programs.
The researchers have other ideas for the future. "We will also consider how program chipping might be combined with other approaches, such as traditional program slicing or debuggers. For example, chipping might be used first and then more refined slicing applied to the best variant to reduce the program further. We will explore the tradeoffs in when and how the two techniques might be used together. We also plan to develop a hybrid, interactive chipping tool. Using such a tool, a developer who has some idea (initially or as simplification proceeds) of where the symptom is occurring, will be able to guide simplification. The developer will be able to instruct the tool to focus on the particular section of code and be able to pick particular simplifications to apply. The tool will be GUI-based and will allow the developer to easily see the differences between variants as they are generated.
I'm sure this approach can work with simple programs. And the two researchers have applied their software to the Java compiler itself. But I've been in charge of projects of several millions lines of code and I'm not sure if their code would be useful. Any thoughts?
Sources: UC Davis news release, September 28, 2007; and various websites
You'll find related stories by following the links below.