Chadd Williams


Research Statement

Teaching Statement

Curriculum vitae

Publications

Dissertation

My new home
Computer Science @ Pacific University

4140 AV Williams Building
University of Maryland
College Park, MD 20740

Research Summary:

My research interests lie in the tools and techniques aspects of programming languages --
driven by what can be discovered about a software project by studying its change history. 
Source code revision repositories hold a wealth of information that is not only useful for
managing and building source code, but also as a detailed log of how, exactly, the source
code has evolved  during development. If a piece of the source code is refactored, evidence
of this will be in the repository.  The code describing how to use the software pre- and
post-refactoring will exist in the repository. As bugs are fixed in the code, the fixes are added
to the repository alongside the buggy code. As the code
evolves and new rules develop
detailing how to use internal functions, they are implicitly documented in the source code,
no matter if they are ever formally documented. My hypothesis was that by examining
the changes made to the source code over time, interesting properties that describe
the source code could be discovered.


Selected Photos

Dyninst API Work:

The Dyninst API is a platform independent API for dynamically instrumenting an
executing binary. Dynamic instrumentation has been used to do runtime performance
analysis of applications, computational steering and dynamic program analysis. 

The model for using the Dyninst API has been to write a tool (the mutator) using the
API to attach to a running process and insert instrumentation into that process. Only
the mutatee's process image in memory is updated with the instrumentation code; 
therefore the mutations are lost when the mutatee process terminates.

Starting a mutator process, parsing the symbol table of the mutatee and inserting
(possibly) large amounts of instrumentation code can have a significant cost. My 
work for this project implements a technique that allows users to save a copy of 
the mutatee, with all the mutations in place, back to disk as a runnable executable
file. The new executable can then be run as a stand alone application, without
the need for a mutator process to recreate and reinsert the mutations. If the user 
wants to run the same mutator/mutatee pair multiple times with exactly the same
mutations, producing a mutated executable will save this initial setup cost for the
subsequent runs. Moreover, the mutated executable is more suitable for batch 
processing environments than the mutator/mutatee model. The executable 
saving mechanism is currently implemented in the Dyninst API for Solaris, Linux
and AIX.