Diver Wants to Take the Guess Work out of Development
The Dynamic Interactive Views for Reverse Engineering project (Diver, for short) has recently celebrated its 0.3.0 release, with reduced back trace sizes and functionality for distinguishing which method calls are unique to a particular trace. JAXenter spoke to project creator Del Myers, on the release....
JAXenter: How does Diver help the Eclipse developer?
Del Myers: Diver is designed to augment the normal development/maintenance process of typical developers. It is meant to aid developers in answering questions about how their software works when other methods fail. For example, when a developer normally has to work on a particular feature of software that doesn't have sufficient documentation to locate exactly where it is, he or she will typically have to start guessing about keywords that might match the concept that the feature implements, or start browsing through code, setting breakpoints for the debugger to stop on in hopes of finding the right location. Diver takes the guess work out of that process by revealing to the user what happens at runtime when the feature gets invoked. It offers advanced filters which help users to narrow the scope of their search to the code that specifically implements the feature that they are looking for. It also offers a fully interactive, advanced sequence diagram view with many unique features. This helps developers who are more visually inclined see the actions of the running software in one screen without having to page through dozens or hundreds of source code files. All the views are linked seamlessly and gathering traces is as simple as just running your software (no additional compile steps for instrumentation) so that Diver can be easily integrated into normal work processes.
JAXenter: The latest release introduces a way to view method calls unique to a particular trace, directly within the sequence diagram. How is this achieved?
Del Myers: That was a tricky problem because the amount of data that must be presented in a sequence diagram like this tends to be extraordinarily large which prevents real-time processing. I can't tell you everything because we hope to possibly publish a paper on it, but this is the basic idea: Diver has an analysis step which is performed after each trace is completed. This analysis is done so that the elements in the trace can be indexed for quick retrieval and user interface responsiveness. At that time, each method invocation is given a unique identifier which can be used to locate the position of the invocation within the call tree. In other words, we can discover which method call is an invocations "parent" and which ones are its children just by looking at the id. Then what we do is apply the same basic filter that is applied in the package explorer to locate invocations that are unique to a particular trace. The ids mentioned before allow us to recognize efficiently which other method invocations led to those unique calls.
JAXenter: What steps does Diver 0.3.0 take to reduce trace sizes?
Del Myers: The philosophy of Diver is that
effort is more costly than disk space. Disk sizes are getting
larger and larger, but we always have more work to do in our day.
So, Diver doesn't offer any serious data compression other than
what is offered by the 3rd-party (HSQLDB) database which is used to
index the trace data. Our raw trace data is stored in compact
binary form. This allows Diver to keep as much information as is
necessary in order to minimize the size of visualizations and
reduce workbench clutter, which translates into lower efforts on
the part of
the use. It does this using the filters that it supplies and by the advanced features in the sequence diagram (such as synchronizing with source code to supply loop compaction).
JAXenter: How does Diver avoid the potential pitfalls of dynamic program analysis –for example, interfering with the execution of the target program?
Del Myers: This is a common problem with all
tools that support dynamic analysis.
There is a sort of software Heisenberg effect because as you try to observe and measure the software, it does affect the running of the software. Fortunately, the only thing that Diver will affect is the speed of the software (and, so, possibly change thread interweaving). We don't do any instrumentation that changes the actual bytecode of the classes being run; we only listen to what they are doing and record it. We do this as efficiently as we possibly can by recording only the minimum amount of data possible, and by storing it in a very compact binary form, but there will, in most large programs, be a noticeable change in the speed of the target software.