Diver Wants to Take the Guess Work out of Development

Diver Interview

Jessica Thornsby

JAXenter speaks to Del Myers on the latest release of his Diver project.

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

JAXenter: How does Diver help the Eclipse

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.

comments powered by Disqus