In its 2002 report [1], the National Institute of Standards and Technology (NIST) estimated that software errors cost the US economy an estimated $59.5 billion annually. Over half of these costs are borne by the end user, while the rest are borne by software developers and vendors. As observed in the report, software is error-ridden, in part, because of its growing complexity. Therefore, software testing and debugging is of primary concern. While better programming languages are being developed that offer fewer possibilities of introducing common bugs, it is still likely that software developed under limited timelines, and by groups of programmers, possibly separated by several time zones, will have numerous oversights. Therefore, in my opinion, efficient and effective code monitoring and debugging support is as important as (if not more important than) developing new programming languages and methodologies.

Dynamic code monitoring is a challenging task. Many different practices and software programs are in use to help programmers determine the existence and location of common bugs, like memory leaks, buffer overflow, accessing freed memory, value-invariant violations, and overwritten stacks. Depending on the programming style and the method selected, the cost and the resulting efficiency of trapping the bugs can be overwhelming. Therefore, an efficient and more effective debugging scheme is highly desirable.

The authors of this paper present promising architectural support for dynamic monitoring. The “Intelligent Watcher” (iWatcher) is a location-controlled monitoring (LCM) scheme in which access to certain memory locations is monitored. iWatcher also can leverage thread-level speculation (TLS), to reduce monitoring overhead and to roll back and reexecute bad code. The iWatcher scheme relies on hardware support to define LCM registers. It provides simple system calls, which can also be inserted automatically, to turn monitoring on and off for certain memory locations. Accesses to these locations trigger a monitoring function defined in the system call. iWatcher, however, leaves the correctness of the triggered function to the programmer. If the monitoring function is successfully completed, the program continues normally. Upon failure, different actions can be defined.

The simplicity of implementing iWatcher, combined with its flexibility, makes it a very powerful monitoring approach. Its efficiency and low overhead are also much better when compared to its peers. However, iWatcher is already facing competing debugging techniques that are more flexible with regard to hardware support [2].

The main contribution of this paper is the presentation of a powerful methodology for monitoring. Overall, it is clear in its presentation, though certain taxonomy-related repeats could have been avoided. The validation methodology is careful and thorough. The authors put a lot of effort into comparing this approach with other available standard software programs. However, the main programming languages of concern seem to be C and C++. It will be interesting to see how effective the approach will be for code that is written in Java and C#.