ernst.bib

%%% Publications of Michael D. Ernst

% This file (and pag.bib) is processed by the bibtex2web program.  See
%   https://homes.cs.washington.edu/~mernst/software/bibtex2web.html
% for an explanation of the fields.

%% Keep in sync with ~/public_html/research/pubs-bytopic-categories,
%% which is used for sorting.  Catch-all categories such as "Dynamic
%% analysis", "Static analysis", "Testing", and "Verification" are mostly
%% for papers that don't fit anywhere else.  Don't clutter those categories
%% with lots of papers that appear elsewhere.
%   category = "Defect prediction",
%   category = "Concurrency",
%   category = "Distributed systems",
%   category = "Dynamic analysis",
%   category = "Education",
%   category = "Immutability (side effects)",
%   category = "Specification inference",
%   category = "Miscellaneous",
%   category = "Natural language processing",
%   category = "Programming language design",
%   category = "Refactoring",
%   category = "Security",
%   category = "Software engineering",
%   category = "Speculative analysis",
%   category = "Static analysis",
%   category = "Synthesis",
%   category = "Testing",
%   category = "Theory",
%   category = "User interfaces",
%   category = "Mobile applications",
%   category = "Verification",
%   FUTUREcategory =  "Databases",
%   OLDcategory =     "Software engineering",
%   OPTcategory =  "",
%   subcategory = "Slicing",


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%% 1989
%%%

@InProceedings{Ernst89a,
  author="Michael D. Ernst",
  title="ML typechecking is not efficient",
  booktitle="Papers of the MIT ACM Undergraduate Conference",
  year=1989,
  month=apr,
  basefilename = "mltypechecking-mitacmug1989",
  nodownloads = 1,
  category = "Theory",
  csetags = "mernst,mernst-Theory,plse",
  summary =
   "ML programmers have the intuition that ML's typechecking algorithm runs
    in linear time.  This paper is an early description of the surprising
    result (not due to me) that ML typechecking runs in time much worse
    than exponential in the size of its input.",
  nonPAG = 1,
}


@MastersThesis{Ernst89,
  author = 	 "Michael D. Ernst",
  title = 	 "Adequate Models for Recursive Program Schemes",
  school = 	 miteecs,
  year = 	 1989,
  type = 	 "Bachelors thesis",
  address = 	 MITaddr,
  month = 	 jun,
  abstract =
   "This thesis is a pedagogical exposition of adequacy for recursive program
    schemes in the monotone frame.
    Adequacy relates the operational and denotational meanings of a term; it
    states that for any term of base type, the operational and denotational
    meanings are identical.  Adequacy is typically proved in the continuous
    frame.  This is a pedagogically questionable step; in order to prove
    adequacy (or some other property) of a pair of semantics, it would be
    desirable to show the property directly, without introducing superfluous
    notions.  This difficulty is particularly acute because, in general, not
    all monotone functions are continuous.
    \par
    This thesis attempts to work out the concept of adequacy for a class of
    monotone first-order recursive program schemes, using Vuillemin and Manna's
    method of ``safe'' computation rules.  The attempt is very nearly
    successful, but at a crucial point the fact that the scheme-definable
    functions are, in fact, continuous as well as monotone must be used.",
  basefilename = "rpsmodel-ernst-bsthesis",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/rpsmodel-ernst-bsthesis.pdf PDF",
  category = "Theory",
  csetags = "mernst,mernst-Theory,plse",
  summary =
   "This paper is a pedagogical exposition of adequacy for recursive
    program schemes in the monotone frame.  Adequacy states that for any
    term of base type, the operational and denotational meanings are
    identical, and it is typically proved in the continuous frame.",
  nonPAG = 1,
}


@InProceedings{ErnstF89,
  author = 	 "Michael D. Ernst and Bruce E. Flinchbaugh",
  title = 	 "Image/map correspondence using curve matching",
  OPTpages = 	 "",
  booktitle =    "AAAI Spring Symposium on Robot Navigation",
  year = 	 1989,
  OPTorganization = "",
  OPTpublisher = "",
  address = 	 "Stanford, CA",
  month = 	 Mar # "~28--30,",
  note = 	 "Also published as Texas Instruments Technical Report
                  CSC-SIUL-89-12",
  OPTannote = 	 "",
  abstract =
   "We address the general practical problem of determining correspondences
    between maps and terrain images, and focus on a static low altitude
    airborne scenario. For this case we consider the approach of partially
    matching detected and expected curves in the image plane. Expected
    curves are generated from a map, using an estimate of the sensor pose
    in three dimensions, and matched with simulated detected curves in an
    image. We also outline a method for sensor pose refinement using point
    correspondences derived from curve matches as input to a relative
    orientation algorithm.",
  basefilename = "curvematch-aaai1989",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/curvematch-aaai1989.pdf PDF",
  category = "Miscellaneous",
  csetags = "mernst,mernst-Artificial-intelligence,plse",
  summary =
   "Correspondences between a real-world image and a map or terrain model
    can assist in navigation.  This paper describes a technique to find
    such correspondences by focusing only on salient curves (roads, rivers,
    ridgelines, etc.) rather than the entire image.",
  nonPAG = 1,
}


@Unpublished{Ernst89c,
  author = 	 "Michael D. Ernst",
  title = 	 "Self-reference in {English}",
  year =	 1989,
  month =	 may,
  OLDnote = 	 "Unpublished manuscript",
  note =
   "The idea from this unpublished term paper was written up by Boolos without
    Ernst's knowledge, to appear as ``Quotational Ambiguity,'' by George
    Boolos, in {\em On Quine}, (Paulo Leonardi, ed.), pp.~283--296, Cambridge
    University Press, 1995.  Boolos called the idea ``Ernst's Paradox'' but
    refused Ernst's request for coauthorship.",
  basefilename = "self-reference-1989",
  nodownloads = 1,
  category = "Miscellaneous",
  csetags = "mernst,mernst-Miscellaneous,plse",
  summary =
   "This paper shows that certain types of linguistic paradoxes cannot
    themselves be expressed without special linguistic conventions; this
    fact has since been dubbed ``Ernst's Paradox''.
    This paper is recapitulated by ``Quotational Ambiguity,'' by George
    Boolos, in {\em Proceedings of the Conference in Honor of
    W. V. O. Quine}, San Marino, May 1990 (edited by Paulo Leonardi).",
  nonPAG = 1,
}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%% 1990
%%%

@TechReport{AIV7,
  author = 	 "Randall Davis and Michael D. Ernst",
  title = 	 "Intellectual property in computing:  ({H}ow) should software
		  be protected? {A}n industry perspective",
  institution =  "MIT Artificial Intelligence Laboratory",
  year = 	 1990,
  type =         "Video",
  number =	 "AIV-7",
  address =	 "Cambridge, Massachusetts",
  month =	 Oct,
  basefilename = "",
  abstract =
   "The future of the software industry is today being shaped in the
    courtroom, with decisions in lawsuits defining the nature of
    intellectual property for software.  While the views of computer
    professionals have at times been heard, the discussion is still being
    played out in the courts, argued by lawyers, and framed as
    fundamentally a legal question: ``What does the existing law say should
    be done?''
    \par
    An alternative view holds that the issue ought to be discussed by those
    in the software industry, and that the crucial question is not what the
    current law is, but rather what it ought to be.  To begin addressing
    this question, MIT sponsored a panel discussion on October 30th, 1990,
    with panelists from industry engaging in lively discussion and debate
    on a variety of positions.",
  alternateAbstract =
   "Speakers: Frank Ingari, Vice President, Lotus Development Corp.;
    Mitchell Kapor, CEO, On Technology; John Landry, CEO, Agility Systems;
    Tom Lemberg, Chief Counsel, Lotus Development Corp.; Randall Davis
    (Moderator)",
  supersededby = "AIM1369 A videotape",
  nonPAG = 1,
}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%% 1992
%%%


@TechReport{AIM1369,
  author = 	 "Michael D. Ernst",
  title = 	 "Intellectual property in computing:  ({How}) should software
		  be protected? {An} industry perspective",
  institution =  "MIT Artificial Intelligence Laboratory",
  type =         "Memo",
  year = 	 1992,
  number =	 "AIM-1369",
  address =	 "Cambridge, Massachusetts",
  month =	 may,
  abstract =
   "Recent legal developments may have a greater impact on the computer
    industry than technological ones. Some courts have ruled that copyright
    law can protect the ``look and feel'' of user interfaces, and patent
    law is increasingly being used to erect formidable barriers around
    software. Some analysts say that these developments will enfeeble an
    otherwise vibrant software industry, creating monopolies by providing
    protection where none is needed or desired. Others argue that the
    interpretations aren't new and that they will provide the protection
    essential to promote innovation and disclosure.
    \par
    Who's right? And who's arguing these questions, anyway?
    \par
    The future of the software industry is today being shaped in the
    courtroom. Decisions in lawsuits are defining the nature of
    intellectual property for software and hence the character of the
    industry. While the views of computer professionals have at times been
    heard, the discussion is still being played out in the courts, argued
    by lawyers, and framed as fundamentally a legal question: ``What does
    the existing law say should be done?''
    \par
    An alternative view holds that the issue ought to be discussed by those
    in the software industry and that the crucial question is not what the
    current law is, but rather what it ought to be. The fundamental issue
    is what shape and character of the industry would be best for all
    concerned. After addressing that we can consider what laws would bring
    this about.
    \par
    To begin addressing this question, the MIT Artificial Intelligence
    Laboratory, the Laboratory for Computer Science, and the Center for
    Coordination Science are hosting a panel discussion on October
    30th. Panelists from industry will speak from their extensive
    experience, offering a variety of perspectives on what forms of
    protection would best serve both the software industry and society in
    general:
    \par
    John Warnock (CEO and co-founder of Adobe Systems) has faced
    interesting and difficult decisions regarding what to keep proprietary
    and what to place in the public domain, in an attempt to balance the
    strategies of licensing proprietary technology and of providing open
    specifications that become widely used.
    \par
    Frank Ingari (Lotus Development Corp., currently in charge of the
    Emerging Markets Business Group) had first-hand experience with a
    variety of intellectual property protection questions surrounding 1-2-3
    while head of Lotus' PC Spreadsheet Division.
    \par
    Mitchell Kapor (Chairman, CEO and founder of On Technology, founder of
    Lotus Development Corp.) has extensive entrepreneurial experience in
    the software industry and has testified before Congress about
    appropriate protection for software.
    \par
    John Landry (Chairman, CEO, and co-founder of Agility Systems and
    previously Executive Vice President of Development at Cullinet
    Software) has been involved in the creation and development of numerous
    software companies and is the Chairman of the ADAPSO computer virus
    committee.
    \par
    Tom Lemberg (Chief Counsel, Lotus Development Corp.) is an expert on
    international law and international attitudes toward intellectual
    property; he will contribute a perspective on the ramifications for
    legal decisions and business practices in the US.
    \par
    Randall Davis (Moderator; Professor of Management, Professor of
    Computer Science, Associate Director of the MIT AI Lab), has served as
    panelist in a National Academy of Science workshop on Intellectual
    Property and Software, and as the court's expert witness in a software
    copyright infringement case.
    \par
    The panelists will make brief presentations, and ample time will be
    provided for audience participation. Some additional questions to be
    considered include:
    \par How should we balance the interests of established companies, start-ups, and users?
    \par How can we motivate innovation and iterative improvement, yet protect investment in
    software?
    \par Where is the value in software?
    \par What should be the bounds on intellectual property? Can (and should) an interface
    or language be owned?
    \par
    The panel will offer information on all sides of this complex issue and
    encourage the software community to consider the consequences of
    various approaches. The discussion is intended to initiate thought
    about what kind of industry makes sense for software and how the legal
    system can be used to achieve it.",
  basefilename = "ipcolloq-transcript-aim1369",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/ipcolloq-press-release.pdf press release;
    https://homes.cs.washington.edu/~mernst/pubs/ipcolloq-transcript-aim1369.pdf PDF",
  category = "Miscellaneous",
  csetags = "mernst,mernst-Miscellaneous,plse",
  summary =
   {This was the first colloquium on intellectual property in computing to
    bring the debate to the technical and social realm; previous analyses
    had been from a narrow legal perspective.  Computer industry executives
    discussed how "look and feel" user interface copyrights and software
    patents could affect the industry.},
  nonPAG = 1,
}

%%%
%%% Serializing
%%%

@InProceedings{Ernst92c,
  author = 	 "Michael D. Ernst",
  title = 	 "Serializing parallel programs (abstract)",
  OMITeditor =	 "Charles E. Leiserson",
  booktitle =	 "Proceedings of the 1992 MIT Student Workshop on VLSI and
		  Parallel Systems",
  pages =	 "13-1 to 13-2",
  year =	 1992,
  month =	 Jul # "~21,",
  category = "Concurrency",
  abstract =
"Programmers would like to be able to write a single program for both
parallel and serial computers.  Historically, the focus has been on
parallelizing serial code.  In this paper, we argue that the
reverse---serializing parallel code---is both more natural and more
efficient.  We introduce and evaluate three methods for serializing
parallel code---unrolling, loop common expression elimination, and finite
differencing---and compare them to parallelization.  All three methods are
based on a form of common subexpression elimination across loop boundaries.",
  supersededby = "Ernst92e",
  nonPAG = 1,
}

@MastersThesis{Ernst92e,
  author = 	 "Michael D. Ernst",
  title = 	 "Serializing parallel programs by removing redundant
		  computation",
  school = 	 MITEECS,
  year = 	 1992,
  address =	 MITaddr,
  month =	 sep,
  supersededby = "Ernst94:Serialize:LCSTR",
  abstract =
"Programs often exhibit more parallelism than is actually available in the
target architecture.  This thesis introduces and evaluates three
methods---{\em loop unrolling}, {\em loop common expression elimination},
and {\em loop differencing}---for automatically transforming a parallel
algorithm into a partially serial one that takes advantage of only the
parallelism available at run time.  The resulting program performs less
computation to produce its results; the running time is not just improved
via second-order effects such as improving use of the memory hierarchy or
reducing overhead (these optimizations can further improve performance,
however).  The asymptotic complexity is not usually reduced, but the
constant factors can be lowered significantly, often by a factor of 4 or
more.  The basis for these methods is the detection of {\em loop common
expressions}, or common subexpressions in different iterations of a
parallel loop.  The loop differencing method also permits computation of
just the change in an expression from iteration to iteration.
\par
We define the class of {\em generalized stencil computations}, in which
loop common expressions can be easily found; each result combines $w$
operands, so a naive implementation requires $w$ operand evaluations and
$w-1$ combining operations per result.  Unrolling and application of our
common subexpression elimination algorithm can reduce its cost to less
than 2 operand evaluations and 3 combining operations per result.  Loop
common expression elimination decreases these costs to 1 and $\log w$,
respectively; when combined with unrolling they drop to 1
operand evaluation and 4 combining operations per result.  Loop
differencing reduces the per-result costs to 2 operand evaluations and 2
combining operations.  We discuss the tradeoffs among these techniques and
when each should be applied.
\par
We can achieve such speedups because, while the maximally parallel
implementation of an algorithm achieves the greatest speedup on a parallel
machine with sufficiently many processors, it may be inefficient when run
on a machine with too few processors.  Serial implementations run faster on
single-processor computers but often contain dependences which prevent
parallelization.  Our methods combine the efficiency of good serial
algorithms with the ease of writing, reading, debugging, and detecting
parallelism in high-level programs.
\par
Our three methods are primarily applicable to MIMD and SIMD implementations
of data-parallel languages when the data set size is larger than the number
of processors (including uniprocessor implementations), but they can also
improve the performance of parallel programs without serializing them.  The
methods may be applied as an optimization of a parallelizing compiler after
a serial program's parallelism has been exposed, and they are also
applicable to some serial programs.",
  category = "Concurrency",
  supersededby = "Ernst94:Serialize:LCSTR",
  nonPAG = 1,
}


@Manual{Ernst92d,
  title = 	 "{EDB} Manual:  An {Emacs} Database",
  author =	 "Michael D. Ernst",
  year =	 1992,
  month =	 Aug,
  note =	 "For EDB 1.02",
  omitfromcv =   1,
  supersededby = "Ernst93a",
  nonPAG = 1,
}


%%%
%%% Intellectual property
%%%

@Unpublished{Ernst92g,
  author = 	 "Michael D. Ernst",
  title = 	 "Partial List of Software Patents",
  note = 	 "Annotated on-line bibliography",
  year =	 1992,
  month =	 Apr,
  annote =	 "Available via anonymous ftp from
		  mintaka.csail.mit.edu:/mitlpf/ai/patent-list.",
  omitfromcv =   1,
  nonPAG = 1,
}

@Unpublished{Ernst92h,
  author = 	 "Michael D. Ernst",
  title = 	 "Intellectual property in computing bibliography",
  note = 	 "Annotated on-line bibliography",
  year =	 1992,
  month =	 Apr,
  annote =	 "Available via anonymous ftp from
		  mintaka.csail.mit.edu:/mitlpf/ai/index.",
  omitfromcv =   1,
  nonPAG = 1,
}



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%% 1993
%%%


@Unpublished{ErnstY93,
  author = 	 "Michael D. Ernst and Gideon Yuval",
  title = 	 "A {Heraclitean} {CD-ROM} installer",
  year = 	 1993,
  month =	 Oct # "~27,",
  note =	 "Microsoft confidential report",
  supersededby = "ErnstY94",
  omitfromcv =   1,
  abstract =
   "With most encryption schemes, the same decryption key is always used to
    convert a particular codetext into plaintext.  If a decryption key which
    has been revealed to multiple parties is compromised, it is impossible to
    determine with whom responsibility for the breach lies.  RSA or elliptic
    curve encryption can be used as the basis of a scheme which permits
    multiple distinct decryption keys to each decrypt a two-part codetext.
    Each decryption key encodes (in a public way) information about the party
    to whom it was issued.  Since decryption keys can be traced, their holders
    have an incentive to keep them secret.  We do not address the issue of
    tracking decrypted information back to the decryptor; the plaintext is
    identical for each recipient.  Wide distribution of commercial software on
    CD-ROM and pay-per-view video are among the applications of this scheme.",
  nonPAG = 1,
}


%%%
%%% Konane
%%%

@InProceedings{Ernst93b,
  author = 	 "Michael D. Ernst and Elwyn Berlekamp",
  title = 	 "Playing {Konane} mathematically",
  booktitle =	 "Articles in Tribute to Martin Gardner",
  year =	 1993,
  editor =	 "Scott Kim",
  pages =	 "6--15",
  month =	 Jan # "~16,",
  organization = "Atlanta International Museum of Art and Design",
  abstract =
"This paper presents a combinatorial game-theoretic analysis of Konane, an
ancient Hawaiian stone-jumping game.  The theory~\cite{BerlekampCG82} applies
particularly well to Konane because the first player unable to move loses,
and a game can often be divided into independent subgames whose outcomes
can be combined to determine the outcome of the entire game.  Most modern
games, and most games that have achieved wide popularity, violate one of
these two basic assumptions and so resist combinatorial game-theoretic
analysis; notable exceptions are the endgames of Go, Domineering, and
Dots-and-Boxes.  This paper first describes the game of Konane and the
ideas of combinatorial game theory, then gives values for a number of
interesting positions and shows how to determine when a game can be divided
into noninteracting subgames.  The methods are most applicable to its
endgame.",
  supersededby = "Ernst95:Konane",
  nonPAG = 1,
}

%%%
%%% EDB
%%%

@Manual{Ernst93a,
  title = 	 "{EDB} Manual:  An {Emacs} Database",
  author =	 "Michael D. Ernst",
  year =	 1993,
  month =	 Jun,
  note =	 "For EDB 1.17",
  omitfromcv =   1,
  nonPAG = 1,
}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%% 1994
%%%


@InProceedings{WeiseCES94:POPL,
  author = 	 "Daniel Weise and Roger F. Crew and Michael D. Ernst and
		  Bjarne Steensgaard",
  title = 	 "Value dependence graphs:  Representation without taxation",
  crossref =     "POPL94",
  pages = 	 "297--310",
  abstract =
   "The value dependence graph (VDG) is a sparse dataflow-like representation
    that simplifies program analysis and transformation.  It is a functional
    representation that represents control flow as data flow and makes explicit
    all machine quantities, such as stores and I/O channels.  We are developing
    a compiler that builds a VDG representing a program, analyzes and
    transforms the VDG, then produces a control flow graph (CFG) [ASU86] from
    the optimized VDG.  This framework simplifies transformations and improves
    upon several published results.  For example, it enables more powerful code
    motion than [CLZ86, FOW87], eliminates as many redundancies as [AWZ88,
    RWZ88] (except for redundant loops), and provides important information to
    the code scheduler [BR91].  We exhibit a fast, one-pass method for
    elimination of partial redundancies that never performs redundant code
    motion [KRS92, DS93] and is simpler than the classical [MR79, Dha91] or SSA
    [RWZ88] methods.  These results accrue from eliminating the CFG from the
    analysis/transformation phases and using demand dependences in preference
    to control dependences.",
  basefilename = "vdg-popl94",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/vdg-popl94.pdf PDF",
  NOTsupersededby = "WeiseCES94:TR",
  category = "Static analysis",
  csetags = "mernst,mernst-Static-analysis,plse",
  summary =
   "This paper describes the value dependence graph (VDG), a sparse,
    functional, dataflow-like program representation based on demand
    dependences.  It also presents some of the analyses and transformations
    that the VDG simplifies.",
  nonPAG = 1,
}


@TechReport{WeiseCES94:TR,
  author = 	 "Daniel Weise and Roger F. Crew and Michael D. Ernst and
		  Bjarne Steensgaard",
  title = 	 "Value dependence graphs:  Representation without taxation",
  institution =  "Microsoft Research",
  year =	 1994,
  month =	 Apr # "~13,",
  number =	 "MSR-TR-94-03",
  address =	 "Redmond, WA",
  basefilename = "",
  supersededby = "WeiseCES94:POPL",
  nonPAG = 1,
}


@TechReport{ErnstY94,
  author = 	 "Michael D. Ernst and Gideon Yuval",
  title = 	 "Heraclitean encryption",
  institution =  "Microsoft Research",
  year = 	 1994,
  number =	 "MSR-TR-94-13",
  address =	 "Redmond, WA",
  month =	 Mar # "~3,",
  abstract =
   "Most encryption schemes always use the same decryption key to convert a
    particular codetext into plaintext.  If a decryption key that has been
    revealed to multiple parties is compromised, it is impossible to determine
    who is responsible for the breach.  Heraclitean encryption, which uses
    public-key encryption (for instance, RSA or elliptic curve) as its
    cryptographic basis, permits the encryptor to create as many independent
    decryption keys as desired.  Each decryption key can publicly encode
    information about the party to whom it was issued, so that given a key,
    anyone can determine its owner.  Since decryption keys can be traced, their
    holders have an incentive to keep them secret.
    \par
       We discuss applications of Heraclitean encryption, provide an example
    implementation, discuss weaknesses in that implementation, and explore some
    practicalities of using the scheme.
    \par
       We do not address the issue of tracking decrypted information back to the
    decryptor; the plaintext is identical for each recipient.  Heraclitean
    encryption is applicable to any broadcast medium that can carry proprietary
    information---for instance, pay-per-view video and wide distribution of
    commercial software or databases via CD-ROM or bulletin boards.",
  basefilename = "heraclitean-tr9413",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/heraclitean-tr9413.pdf PDF",
  category = "Theory",
  csetags = "mernst,mernst-Theory,plse",
  summary =
   "Heraclitean encryption permits an encryptor to create many independent
    decryption keys for converting a particular codetext into plaintext.
    This permits tracing of decryption keys and, in the event of a
    compromise, determination of which decryptor leaked his or her key.",
  nonPAG = 1,
}


@TechReport{Ernst94:SlicingTR9414,
  author = 	 "Michael D. Ernst",
  title = 	 "Practical fine-grained static slicing of optimized code",
  institution =  "Microsoft Research",
  year = 	 1994,
  number =	 "MSR-TR-94-14",
  address =	 "Redmond, WA",
  month =	 Jul # "~26,",
  abstract =
   "Program slicing is a technique for visualizing dependences and
    restricting attention to just the components of a program relevant to
    evaluation of certain expressions.  Backward slicing reveals which
    other parts of the program the expressions' meaning depends on, while
    forward slicing determines which parts of the program depend on their
    meaning.  Slicing helps programmers understand program structure, which
    aids program understanding, maintenance, testing, and debugging;
    slicing can also assist parallelization, integration and comparison of
    program versions, and other tasks.
    \par
      This paper improves previous techniques for static slicing.  Our
    algorithm is expression-oriented rather than based on statements and
    variables, resulting in smaller slices.  A user can slice on any value
    computed by the program --- including ones that are not, or cannot be,
    assigned to variables.  The slicer accounts for function calls,
    pointers, and aggregate structures.  It takes advantage of compiler
    analyses and transformations, resulting in more precise slices, and
    bypasses syntactic constraints by directly constructing executable
    slices.  These techniques are implemented in a slicer for the C
    programming language that accepts input via mouse clicks; operates on
    the value dependence graph, a dataflow-like program representation that
    is especially well-suited to slicing; and displays closure slices by
    highlighting portions of the program in the programmer's editor.",
  basefilename = "slicing-tr9414",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/slicing-tr9414.pdf PDF",
  downloads =
   "https://homes.cs.washington.edu/~mernst/pubs/slicing-9705-slides.pdf slides (PDF);
    https://homes.cs.washington.edu/~mernst/pubs/slicing-9705-slides.ppt slides (PowerPoint)",
  category = "Static analysis",
  csetags = "mernst,mernst-Static-analysis,plse",
  subcategory = "Slicing",
  summary =
   "Slicing helps visualize dependences and restrict attention relevant
    program components.  This paper describes techniques, and an
    implementation, for slicing on arbitrary program values, omitting
    irrelevant parts of statements, and exploiting optimizations.",
  nonPAG = 1,
}


% Identical to Ernst94:Serialize:LCSTR
@TechReport{Ernst94:Serialize:MSRTR,
  author = 	 "Michael D. Ernst",
  title = 	 "Serializing parallel programs by removing redundant
		  computation",
  institution =  "Microsoft Research",
  year = 	 1994,
  number =	 "MSR-TR-94-15",
  address =	 "Redmond, WA",
  month =	 Aug # "~21,",
  OPTnote =         "Revision of Master's thesis",
  supersededby = "Ernst94:Serialize:LCSTR A concurrently published technical report",
  category = "Concurrency",
  nonPAG = 1,
}


% Identical to Ernst94:Serialize:MSRTR.
@TechReport{Ernst94:Serialize:LCSTR,
  author = 	 "Michael D. Ernst",
  title = 	 "Serializing parallel programs by removing redundant
		  computation",
  institution =  "MIT Laboratory for Computer Science",
  year = 	 1994,
  number =	 "MIT/LCS/TR-638",
  address =	 "Cambridge, MA",
  month =	 Aug # "~21,",
  OPTnote =         "Revision of Master's thesis; also published as
                  Microsoft Research technical report MSR-TR-94-15",
  abstract =
   "Programs often exhibit more parallelism than is actually available in
    the target architecture.  This thesis introduces and evaluates three
    methods --- {\em loop unrolling}, {\em loop common expression
    elimination}, and {\em loop differencing} --- for automatically
    transforming a parallel algorithm into a less parallel one that takes
    advantage of only the parallelism available at run time.  The resulting
    program performs less computation to produce its results; the running
    time is not just improved via second-order effects such as improving
    use of the memory hierarchy or reducing overhead (such optimizations
    can further improve performance).  The asymptotic complexity is not
    usually reduced, but the constant factors can be lowered significantly,
    often by a factor of 4 or more.  The basis for these methods is the
    detection of loop common expressions, or common subexpressions in
    different iterations of a parallel loop.  The loop differencing method
    also permits computation of just the change in an expression from
    iteration to iteration.
    \par
      We define the class of {\em generalized stencil computations}, in which loop
    common expressions can be easily found; each result combines w operands,
    so a naive implementation requires w operand evaluations and w-1
    combining operations per result.  Unrolling and application of the
    two-phase common subexpression elimination algorithm, which we introduce
    and which significantly outperforms other common subexpression elimination
    algorithms, can reduce its cost to less than 2 operand evaluations and 3
    combining operations per result.  Loop common expression elimination
    decreases these costs to 1 and log w, respectively; when combined with
    unrolling they drop to 1 operand evaluation and 4 combining operations per
    result.  Loop differencing reduces the per-result costs to 2 operand
    evaluations and 2 combining operations.  We discuss the tradeoffs among
    these techniques and when each should be applied.
    \par
      We can achieve such speedups because, while the maximally parallel
    implementation of an algorithm achieves the greatest speedup on a parallel
    machine with sufficiently many processors, it may be inefficient when run
    on a machine with too few processors.  Serial implementations, on the other
    hand, run faster on single-processor computers but often contain
    dependences which prevent parallelization.  Our methods combine the
    efficiency of good serial algorithms with the ease of writing, reading,
    debugging, and detecting parallelism in high-level programs.
    \par
      Our three methods are primarily applicable to MIMD and SIMD implementations
    of data-parallel languages when the data set size is larger than the number
    of processors (including uniprocessor implementations), but they can also
    improve the performance of parallel programs without serializing them.  The
    methods may be applied as an optimization of a parallelizing compiler after
    a serial program's parallelism has been exposed, and they are also
    applicable to some purely serial programs which manipulate arrays or other
    structured data.
    \par
      The techniques have been implemented, and preliminary timing results are
    reported.  Real-world computations are used as examples throughout, and an
    appendix lists more potential applications.",
  basefilename = "serialize-tr638",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/serialize-tr638.pdf PDF",
  category = "Concurrency",
  csetags = "mernst,mernst-Static-analysis,plse",
  summary =
   "This paper introduces and evaluates methods for automatically
    transforming a parallel algorithm into a less parallel one that takes
    advantage of only the parallelism available at run time, thus
    performing less computation to produce the same results.",
  nonPAG = 1,
}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%% 1995
%%%

@TechReport{Ernst95:Slicing_pointers_procedures,
  author = 	 "Michael D. Ernst",
  title = 	 "Slicing pointers and procedures (abstract)",
  institution =  "Microsoft Research",
  year = 	 1995,
  number =	 "MSR-TR-95-23",
  address =	 "Redmond, WA",
  month =	 jan # "~13,",
  abstract =
   "Program slicing restricts attention to the components of a program relevant
    to evaluation of one expression, the slicing criterion.  Our slicer,
    which explicitly represents the store as an aggregate value, is the first
    to support arbitrary pointer manipulations and aggregate values, and is
    faster than more limited techniques.  We also improve the asymptotic
    complexity of slicing in the presence of procedure calls, and of a
    preprocessing step for computing dependences of procedure returns on
    formals.  Additionally, our interprocedural slices can be smaller than
    those produced by other techniques.  We implement these techniques in the
    first slicer for an entire practical programming language (ANSI C, except
    {\tt longjmp}).",
  basefilename = "slicing-tr9523",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/slicing-tr9523.pdf PDF",
  downloads =
   "https://homes.cs.washington.edu/~mernst/pubs/slicing-9705-slides.pdf slides (PDF);
    https://homes.cs.washington.edu/~mernst/pubs/slicing-9705-slides.ppt slides (PowerPoint)",
  category = "Static analysis",
  csetags = "mernst,mernst-Static-analysis,plse",
  subcategory = "Slicing",
  summary =
   "This paper describes how to efficiently extend program slicing to
    arbitrary pointer manipulations, aggregate values, and procedure calls.
    The implementation is the first for an entire practical programming
    language.",
  nonPAG = 1,
}


@Proceedings{IR95:proc,
  title = 	 "IR '95: Intermediate Representations Workshop Proceedings",
  year = 	 1995,
  editor =	 "Michael D. Ernst",
  address =	 "San Francisco, CA",
  month =	 Jan # "~22,",
  note =	 "{\em ACM SIGPLAN Notices} 30(3), March 1995",
  abstract =
   "An intermediate representation is the basis of any tool for manipulating
    computer programs. A good representation permits powerful operations to be
    performed more simply, and may enable operations that a weaker
    representation cannot support. This workshop will examine current trends
    and research in the design and use of intermediate representations. The
    workshop will include a mix of presentation and discussion periods to
    facilitate interaction.",
  basefilename = "ir95-proceedings",
  downloads =    "https://homes.cs.washington.edu/~mernst/meetings/ir95/ workshop website;
		  https://dl.acm.org/citation.cfm?id=202530 ACM proceedings",
  category = "Programming language design",
  csetags = "mernst,mernst-Programming-language-design,plse",
  summary =
   "This workshop examined current trends and research in the design and
    use of intermediate representations for manipulating computer programs.",
  nonPAG = 1,
}

@TechReport{IR95:tr,
  key =          "Ernst",
  editor = 	 "Michael D. Ernst",
  title = 	 "IR '95: Intermediate Representations Workshop
		  Proceedings",
  institution =  "Microsoft Research",
  year = 	 1995,
  number =	 "MSR-TR-95-01",
  address =	 "Redmond, WA",
  month =	 Jan # "~22,",
  supersededby = "IR95:proc",
  nonPAG = 1,
}

@Article{Ernst95:Konane,
  author = 	 "Michael D. Ernst",
  title = 	 "Playing {Konane} mathematically:
		  A combinatorial game-theoretic analysis",
  journal = 	 "UMAP Journal",
  year = 	 1995,
  volume =	 16,
  month =	 "Spring",
  number =	 2,
  pages =	 "95--121",
  abstract =
   "This article presents a combinatorial game-theoretic analysis of
    Konane, an ancient Hawaiian stone-jumping game.  Combinatorial game
    theory [Berlekamp et al.\ 1982] applies particularly well to Konane
    because the first player unable to move loses and because a game often
    can be divided into independent subgames whose outcomes can be combined
    to determine the outcome of the entire game.  By contrast, most popular
    modern games violate the assumptions of combinatorial game-theoretic
    analysis.  This article describes the game of Konane and the ideas of
    combinatorial game theory, derives values for a number of interesting
    positions, shows how to determine when a game can be divided into
    noninteracting subgames, and provides anthropological details about
    Konane.",
  basefilename = "konane-tr9524",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/konane-tr9524.pdf PDF",
  downloads = "https://homes.cs.washington.edu/~mernst/pubs/konane-talk.ppt talk slides (PowerPoint, 1/17/2001);
               https://homes.cs.washington.edu/~mernst/software/games.tar.gz implementation",
  category = "Theory",
  csetags = "mernst,mernst-Theory,plse",
  summary =
   "This paper presents a combinatorial game-theoretic analysis of
    Konane, an ancient Hawaiian stone-jumping game.  Combinatorial game
    theory indicates, for a given board position, which player wins, and
    how great that player's advantage is.",
  nonPAG = 1,
}


@TechReport{Ernst95:Konane:TR,
  author = 	 "Michael D. Ernst",
  title = 	 "Playing {Konane} mathematically:
		  A combinatorial game-theoretic analysis",
  institution =  "Microsoft Research",
  year =	 1995,
  month =	 aug # "~7,",
  number =	 "MSR-TR-95-24",
  address =	 "Redmond, WA",
  basefilename = "konane-tr9524",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/konane-tr9524.pdf PDF",
  supersededby = "Ernst95:Konane",
  nonPAG = 1,
}


@InCollection{Boolos95,
  author = 	 "George Boolos",
  title = 	 "Quotational Ambiguity",
  booktitle =	 "On Quine: New Essays",
  year =	 1995,
  editor =	 "Paulo Leonardi and Marco Santambrogio",
  address =	 "San Marino",
  month =	 may,
  pages =	 "283--296",
  publisher =	 "Cambridge University Press",
  note =	 "Draws heavily on~\cite{Ernst89c}.",
  omitfromcv =   1,
  nonPAG = 1,
}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%% 1996
%%%


@Misc{YuvalE1997,
  author =	 "Gideon A. Yuval and Michael D. Ernst",
  title =	 "Method and system for controlling unauthorized access to
                  information distributed to users",
  howpublished = "U.S. Patent 5,586,186",
  month =	 dec # "~17,",
  year =	 1996,
  note =	 "Assigned to Microsoft Corporation",
  abstract =
   "A system for controlling unauthorized access to information distributed to
    users and, more particularly, for controlling unauthorized access to
    software distributed to users is provided. One method utilizing the system
    of the present invention enables the software to be encrypted using a
    single encryption key and to be decrypted using a multiplicity of
    ``decryption'' keys, each of which is unique to a particular user. The
    ``decryption'' keys are the products of numeric representations of
    identifying information relating to users and unique user keys generated
    using the numeric representations and a ``true'' decryption key. Since each
    user receives a unique user key and both the numeric representation and the
    user key are generated using the identifying information, if the user
    reveals the numeric representation and the user key (or the product of the
    numeric representation and the user key), the numeric representation and
    the user key can be traced to the user who revealed them. Another method
    utilizing the system of the present invention introduces randomness or
    pseudo-randomness into the decryption scheme to provide an additional level
    of security to the scheme.",
  basefilename = "access-patent-5586186",
  downloads =
   "https://patents.google.com/patent/US5586186A/en Google Patents;
    https://patentimages.storage.googleapis.com/d5/7a/e9/7233c72863437c/US5586186.pdf PDF",
  category = "Theory",
  csetags = "mernst,mernst-Theory,plse",
  summary =
   "This patent describes a system with unique decryption keys for each
    purchaser of an encrypted product, so as to determine who revealed a
    decryption key if one is made public.",
  nonPAG = 1,
}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%% 1997
%%%

@InProceedings{ernst-ijcai97,
  author=       "Michael D. Ernst and Todd D. Millstein and Daniel S. Weld",
  title=        "Automatic {SAT}-compilation of planning problems",
  crossref =     "IJCAI97",
  pages=        "1169--1176",
  abstract =
   "Recent work by Kautz {\em et al.}\ provides tantalizing evidence that
    large, classical planning problems may be efficiently solved by
    translating them into propositional satisfiability problems, using
    stochastic search techniques, and translating the resulting truth
    assignments back into plans for the original problems.  We explore the
    space of such transformations, providing a simple framework that
    generates eight major encodings (generated by selecting one of four
    action representations and one of two frame axioms) and a number of
    subsidiary ones.  We describe a fully-implemented compiler that can
    generate each of these encodings, and we test the compiler on a suite
    of STRIPS planning problems in order to determine which encodings have
    the best properties.",
  basefilename = "satcompile-ijcai97",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/satcompile-ijcai97.pdf PDF",
  downloads = "ftp://ftp.cs.washington.edu/pub/ai/medic.tar.gz Medic implementation",
  category = "Miscellaneous",
  csetags = "mernst,mernst-Artificial-intelligence,plse",
  summary =
   "Planning problems can be solved by transformation into a propositional
    satisfiability problem, solution, and transformation of the SAT
    solution into a plan.  This paper describes the first automatic translator
    from planning to SAT and evaluates the space of encodings of planning
    problems as SAT formulas.",
  nonPAG = 1,
}

%%%
%%% 1998
%%%

@InProceedings{ErnstKC98,
  author = 	 "Michael D. Ernst and Craig S. Kaplan and Craig Chambers",
  title = 	 "Predicate dispatching: A unified theory of dispatch",
  crossref =     "ECOOP98",
  pages =        "186--211",
  abstract =
   "{\em Predicate dispatching} generalizes previous method dispatch
    mechanisms by permitting arbitrary predicates to control method
    applicability and by using logical implication between predicates as
    the overriding relationship.  The method selected to handle a message
    send can depend not just on the classes of the arguments, as in
    ordinary object-oriented dispatch, but also on the classes of
    subcomponents, on an argument's state, and on relationships between
    objects.  This simple mechanism subsumes and extends object-oriented
    single and multiple dispatch, ML-style pattern matching, predicate
    classes, and classifiers, which can all be regarded as syntactic sugar
    for predicate dispatching.  This paper introduces predicate
    dispatching, gives motivating examples, and presents its static and
    dynamic semantics.  An implementation of predicate dispatching is
    available.",
  basefilename = "dispatching-ecoop98",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/dispatching-ecoop98.pdf PDF;
    https://homes.cs.washington.edu/~mernst/pubs/dispatching-ecoop98-slides.pdf slides (PDF)",
  downloads =
   "ftp://ftp.cs.washington.edu/homes/chambers/gud.tar.gz implementation;
    https://projectsweb.cs.washington.edu/research/projects/cecil/www/Gud/manual.html manual",
  category = "Programming language design",
  csetags = "mernst,mernst-Programming-language-design,plse",
  summary =
   "Predicate dispatching generalizes and subsumes previous method dispatch
    mechanisms (object-oriented dispatch, pattern matching, and more) by
    permitting arbitrary predicates to control method applicability and by
    using logical implication between predicates as the overriding relationship.",
  nonPAG = 1,
}


@TechReport{ErnstCGN98:TR,
  author = 	 "Michael D. Ernst and Jake Cockrell and
		  William G. Griswold and David Notkin",
  title = 	 "Dynamically discovering likely program invariants to
		  support program evolution",
  institution =  UWCSEDept,
  year = 	 1998,
  address =	 "Seattle, WA",
  month = 	 aug # "~27,",
  number =	 "UW-CSE-98-08-03",
  supersededby = "ErnstCGN2001:TSE",
}


%%%
%%% 1999
%%%

@InProceedings{ErnstCGN99,
  author = 	 "Michael D. Ernst and Jake Cockrell and
		  William G. Griswold and David Notkin",
  title = 	 "Dynamically discovering likely program invariants to
		  support program evolution",
  crossref =     "ICSE99",
  pages = 	 "213--224",
  basefilename = "invariants-icse99",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/invariants-icse99.pdf PDF;
    https://homes.cs.washington.edu/~mernst/pubs/invariants-icse99-slides.pdf slides (PDF)",
  supersededby = "ErnstCGN2001:TSE",
}


@InProceedings{Ernst99,
  author = 	 "Michael D. Ernst",
  title = 	 "Research summary for dynamic detection of program invariants",
  crossref =     "ICSE99",
  pages =	 "718--719",
  basefilename = "invariants-icse99-doctoral-proc",
  supersededby = "Ernst2000:PhD A short research plan",
}

@InProceedings{Ernst99:extended-summary,
  author = 	 "Michael D. Ernst",
  title = 	 "Research summary for dynamic detection of program invariants",
  crossref =     "ICSEDS99",
  NOpages =      "*",
  note =         "Expanded version of two-page summary in ICSE '99
		  proceedings, distributed at workshop",
  basefilename = "invariants-icse99-doctoral-full",
  supersededby = "Ernst2000:PhD A longer research plan",
}

@TechReport{ErnstCGN99relevance,
  author = 	 "Michael D. Ernst and Adam Czeisler and
		  William G. Griswold and David Notkin",
  title = 	 "Quickly detecting relevant program invariants",
  institution =  UWCSEDept,
  year = 	 1999,
  address =	 "Seattle, WA",
  month = 	 nov # "~15,",
  number =	 "UW-CSE-99-11-01",
  supersededby = "ErnstCGN2000:Relevance",
  undergradCoauthor = 1,
}


@TechReport{ErnstGKN99,
  author = 	 "Michael D. Ernst and
		  William G. Griswold and Yoshio Kataoka and David Notkin",
  title = 	 "Dynamically discovering pointer-based program invariants",
  institution =  UWCSEDept,
  year = 	 1999,
  number =	 "UW-CSE-99-11-02",
  address =	 "Seattle, WA",
  month = 	 nov # "~16,",
  note =         "Revised " # mar # "~17, 2000",
  abstract =
   "Explicitly stated program invariants can help programmers by characterizing
    aspects of program execution and identifying program properties that must
    be preserved when modifying code; invariants can also be of assistance to
    automated tools.  Unfortunately, these invariants are usually absent from
    code.  Previous work showed how to dynamically detect invariants by looking
    for patterns in and relationships among variable values captured in program
    traces.  A prototype implementation, Daikon, recovered invariants from
    formally-specified programs, and the invariants it detected assisted
    programmers in a software evolution task.  However, it was limited to
    finding invariants over scalars and arrays.  This paper presents two
    techniques that enable discovery of invariants over richer data structures,
    in particular collections of data represented by recursive data structures,
    by indirect links through tables, etc.  The first technique is to traverse
    these collections and record them as arrays in the program traces; then the
    basic Daikon invariant detector can infer invariants over these new trace
    elements.  The second technique enables discovery of conditional
    invariants, which are necessary for reporting invariants over recursive
    data structures and are also useful in their own right.  These techniques
    permit detection of invariants such as ``p.value > limit or p.left in
    mytree''.  The techniques are validated by successful application to two sets
    of programs:  simple textbook data structures and student solutions to a
    weighted digraph problem.",
  basefilename = "invariants-pointers-tr991102-20000317",
  downloads = "https://plse.cs.washington.edu/daikon/ Daikon implementation",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/invariants-pointers-tr991102-20000317.pdf PDF",
  category = "Specification inference",
  csetags = "mernst,notkin,mernst-Invariant-detection,plse",
  summary =
   "This paper extends dynamic invariant detection to pointer-directed data
    structures by linearizing those structures and, more significantly, by
    permitting inference of disjunctive invariants (like ``A or B'').",
}



@TechReport{ErnstBN99TR,
  author = 	 "Michael D. Ernst and Greg J. Badros and David Notkin",
  title = 	 "An empirical analysis of {C} preprocessor use",
  institution =  UWCSEDept,
  year = 	 1997,
  number =	 "UW-CSE-97-04-06",
  address =	 "Seattle, WA",
  month =	 apr # "~22,",
  note =         "Revised " # mar # "~31, 1999",
  basefilename = "c-preprocessor-tr970406",
  supersededby = "ErnstBN2002:TSE",
}



%%%
%%% 2000
%%%


@InProceedings{ErnstCGN2000:Relevance,
  author = 	 "Michael D. Ernst and Adam Czeisler and
		  William G. Griswold and David Notkin",
  title = 	 "Quickly detecting relevant program invariants",
  crossref =     "ICSE2000",
  pages =	 "449--458",
  abstract =
   "Explicitly stated program invariants can help programmers by characterizing
    certain aspects of program execution and identifying program properties
    that must be preserved when modifying code.  Unfortunately, these
    invariants are usually absent from code.  Previous work showed how to
    dynamically detect invariants from program traces by looking for patterns
    in and relationships among variable values.  A prototype implementation,
    Daikon, accurately recovered invariants from formally-specified programs,
    and the invariants it detected in other programs assisted programmers in a
    software evolution task.  However, Daikon suffered from reporting too many
    invariants, many of which were not useful, and also failed to report some
    desired invariants.
    \par
    This paper presents, and gives experimental evidence of the efficacy of,
    four approaches for increasing the relevance of invariants reported by a
    dynamic invariant detector.  One of them{\,---\,}exploiting unused
    polymorphism{\,---\,}adds desired invariants to the output.  The other
    three{\,---\,}suppressing implied invariants, limiting which variables are
    compared to one another, and ignoring unchanged values{\,---\,}eliminate
    undesired invariants from the output and also improve runtime by reducing
    the work done by the invariant detector.",
  basefilename = "invariants-relevance-icse2000",
  downloadsnonlocal =
    "https://homes.cs.washington.edu/~mernst/pubs/invariants-relevance-icse2000.pdf PDF",
  downloads = "https://plse.cs.washington.edu/daikon/ Daikon implementation",
  category = "Specification inference",
  csetags = "mernst,notkin,mernst-Invariant-detection,plse",
  summary =
   "Dynamic invariant detection can output many unhelpful properties as
    well as those of interest.  This paper gives four techniques that
    eliminate uninteresting invariants or add relevant ones, thus
    increasing the technique's usefulness to programmers.",
  undergradCoauthor = 1,
}
%%  note =         "To appear in \bgroup\em " # tosem # "\egroup",



@PhdThesis{Ernst2000:PhD,
  author = 	 "Michael D. Ernst",
  title = 	 "Dynamically Discovering Likely Program Invariants",
  school = 	 UWCSEDept,
  year = 	 2000,
  address =	 "Seattle, Washington",
  month =	 aug,
  abstract =
   "This dissertation introduces dynamic detection of program invariants,
    presents techniques for detecting such invariants from traces, assesses
    the techniques' efficacy, and points the way for future research.
    \par
    Invariants are valuable in many aspects of program development, including
    design, coding, verification, testing, optimization, and maintenance.
    They also enhance programmers' understanding of data structures,
    algorithms, and program operation.  Unfortunately, explicit invariants
    are usually absent from programs, depriving programmers and automated
    tools of their benefits.
    \par
    This dissertation shows how invariants can be dynamically detected from
    program traces that capture variable values at program points of
    interest.  The user runs the target program over a test suite to create
    the traces, and an invariant detector determines which properties and
    relationships hold over both explicit variables and other expressions.
    Properties that hold over the traces and also satisfy other tests, such
    as being statistically justified, not being over unrelated variables, and
    not being implied by other reported invariants, are reported as likely
    invariants.  Like other dynamic techniques such as testing, the quality
    of the output depends in part on the comprehensiveness of the test suite.
    If the test suite is inadequate, then the output indicates how,
    permitting its improvement.  Dynamic analysis complements static
    techniques, which can be made sound but for which certain program
    constructs remain beyond the state of the art.
    \par
    Experiments demonstrate a number of positive qualities of dynamic
    invariant detection and of a prototype implementation, Daikon.  Invariant
    detection is accurate{\,---\,}it rediscovers formal
    specifications{\,---\,}and useful{\,---\,}it assists programmers in
    programming tasks.  It runs quickly and produces output of modest size.
    Test suites found in practice tend to be adequate for dynamic invariant
    detection.",
  basefilename = "invariants-ernst-phdthesis",
  downloadsnonlocal =
    "https://homes.cs.washington.edu/~mernst/pubs/invariants-ernst-phdthesis.pdf PDF",
  downloads = "https://plse.cs.washington.edu/daikon/ Daikon implementation",
  category = "Specification inference",
  csetags = "mernst,mernst-Invariant-detection,plse",
  summary =
   "This dissertation overviews dynamic invariant detection as of summer
    2000.  It includes materials from the papers on the basic invariant
    detection techniques (IEEE TSE, 2001), relevance improvements (ICSE
    2000), and extensions to pointer-based data structures (UW TR, 1999)."
}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%% 2001
%%%

@Article{ErnstCGN2001:TSE,
  author = 	 "Michael D. Ernst and Jake Cockrell and
		  William G. Griswold and David Notkin",
  title = 	 "Dynamically discovering likely program invariants to
		  support program evolution",
  journal = 	 TSE,
  year = 	 2001,
  volume =	 27,
  number =	 2,
  pages =	 "99--123",
  month = 	 feb,
  OMITnote = 	 ErnstCGN2001TSEnote,
  abstract =
   "Explicitly stated program invariants can help programmers by identifying
    program properties that must be preserved when modifying code.  In
    practice, however, these invariants are usually implicit.  An alternative
    to expecting programmers to fully annotate code with invariants is to
    automatically infer likely invariants from the program itself.  This
    research focuses on dynamic techniques for discovering invariants from
    execution traces.
    \par
    This article reports three results.  First, it describes techniques for
    dynamically discovering invariants, along with an implementation, named
    Daikon, that embodies these techniques.  Second, it reports on the
    application of Daikon to two sets of target programs.  In programs from
    Gries's work on program derivation, the system rediscovered predefined
    invariants.  In a C program lacking explicit invariants, the system
    discovered invariants that assisted a software evolution task.  These
    experiments demonstrate that, at least for small programs, invariant
    inference is both accurate and useful.  Third, it analyzes scalability
    issues such as invariant detection runtime and accuracy as functions of
    test suites and program points instrumented.",
  basefilename = "invariants-tse2001",
  downloadsnonlocal =
    "https://homes.cs.washington.edu/~mernst/pubs/invariants-tse2001.pdf PDF",
  downloads =
    "https://homes.cs.washington.edu/~mernst/pubs/invariants-icse99.pdf ICSE 1999 paper (PDF);
     https://homes.cs.washington.edu/~mernst/pubs/invariants-icse99-slides.ppt ICSE 1999 talk slides (PowerPoint);
     https://homes.cs.washington.edu/~mernst/pubs/invariants-icse99-slides.pdf ICSE 1999 talk slides (PDF);
     https://plse.cs.washington.edu/daikon/ Daikon implementation",
  category = "Specification inference",
  csetags = "mernst,notkin,mernst-Invariant-detection,plse",
  summary =
   "Program properties (such as formal specifications or assert statements)
    are useful for a variety of programming tasks.  This paper shows how to
    dynamically infer program properties by looking for patterns and
    relationships among values computed at run time.",
}

@InProceedings{Ernst01:ICSEpanel,
  author = 	 "David Notkin and Marc Donner and Michael D. Ernst and
                  Michael Gorlick and Whitehead, Jr., E. James",
  title = 	 "Panel: Perspectives on software engineering",
  crossref =     "ICSE2001",
  pages = 	 "699--702",
  abstract =
   "This panel gives a non-standard view of the future of software
    engineering.  Two of the speakers are recent Ph.D. graduates in
    computer science, with expertise in software engineering, who have
    taken academic positions; as people who will educate the next
    generation of software engineering practitioners and researchers, they
    provide a key vision of the future.  The other two speakers are senior,
    having moved from the research community into a world in which they
    face the problems of engineering software on a daily basis.
    Collectively, along with interactions from the audience, these two
    often underrepresented perspectives provide a sense of the key
    directions in which software engineering --- practice, research, and
    education --- should and must go.",
  basefilename = "se-perspectives-panel-icse2001",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/se-perspectives-panel-icse2001.pdf PDF",
  downloads =
   "https://homes.cs.washington.edu/~notkin/icse2001panel.htm slides (for all panelists)",
  category = "Software engineering",
  csetags = "notkin,mernst,mernst-Software-engineering,plse",
  summary =
   "This talk argues that tools are key to having impact on software
    engineering; they must be published; case studies are more fruitful
    than experiments; researchers have the responsibility to target the
    state of the art; static and dynamic tools should be combined; and
    lightweight formal tools are the right place to start.",
}


@InProceedings{NimmerE01:RV,
  author = 	 "Jeremy W. Nimmer and Michael D. Ernst",
  title = 	 "Static verification of dynamically detected program
		  invariants: Integrating {Daikon} and {ESC}/{Java}",
  crossref = 	 "RV2001",
  NOpages = 	 "pages are numbered 1-22",
  abstract =
   "This paper shows how to integrate two complementary techniques for
    manipulating program invariants: dynamic detection and static verification.
    Dynamic detection proposes likely invariants based on program
    executions, but the resulting properties are not guaranteed to be true over
    all possible executions.  Static verification checks that properties are
    always true, but it can be difficult and tedious to
    select a goal and to annotate programs for input to a static checker.
    Combining these techniques overcomes the weaknesses of each: dynamically
    detected invariants can annotate a program or provide goals for static
    verification, and static verification can confirm properties proposed by a
    dynamic tool.
    \par
    We have integrated a tool for dynamically detecting likely program
    invariants, Daikon, with a tool for statically verifying program
    properties, ESC/Java.  Daikon examines run-time values of program
    variables; it looks for patterns and relationships in those values, and it
    reports properties that are never falsified during test runs and that
    satisfy certain other conditions, such as being statistically justified.
    ESC/Java takes as input a Java program annotated with preconditions,
    postconditions, and other assertions, and it reports which annotations
    cannot be statically verified and also warns of potential runtime errors,
    such as null dereferences and out-of-bounds array indices.
    \par
    Our prototype system runs Daikon, inserts its output into code as ESC/Java
    annotations, and then runs ESC/Java, which reports unverifiable
    annotations.  The entire process is completely automatic, though users may
    provide guidance in order to improve results if desired.  In preliminary
    experiments, ESC/Java verified all or most of the invariants proposed by
    Daikon.",
  basefilename = "invariants-verify-rv2001",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/invariants-verify-rv2001.pdf PDF",
  category = "Specification inference,Verification",
  csetags = "mernst,mernst-Verification,plse",
  summary =
   "Dynamic invariant detection proposes likely (not certain) invariants;
    static verification requires program explicit identification of a goal
    and program annotation.  This paper combines the two techniques to
    overcome the weaknesses of each.",
  usesDaikon = 1,
  undergradCoauthor = 1,
}


@InProceedings{KataokaEGN01,
  author = 	 "Yoshio Kataoka and Michael D. Ernst and William G. Griswold and David Notkin",
  title = 	 "Automated support for program refactoring using invariants",
  crossref =     "ICSM2001",
  pages =	 "736--743",
  abstract =
   "Program refactoring{\,---\,}transforming a program to improve
    readability, structure, performance, abstraction, maintainability, or
    other characteristics{\,---\,}is not applied in practice as much as
    might be desired.  One deterrent is the cost of detecting candidates
    for refactoring and of choosing the appropriate refactoring
    transformation.  This paper demonstrates the feasibility of
    automatically finding places in the program that are candidates for
    specific refactorings.  The approach uses program invariants: when
    particular invariants hold at a program point, a specific refactoring
    is applicable.  Since most programs lack explicit invariants, an
    invariant detection tool called Daikon is used to infer the required
    invariants.  We developed an invariant pattern matcher for several
    common refactorings and applied it to an existing Java code base.
    Numerous refactorings were detected, and one of the developers of the
    code base assessed their efficacy.",
  basefilename = "refactoring-icsm2001",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/refactoring-icsm2001.pdf PDF",
  category = "Specification inference,Refactoring",
  csetags = "mernst,notkin,mernst-Refactoring,plse",
  summary =
   "This paper shows how program invariants can productively be used to
    identify candidate refactorings, which are small-scale program
    transformations that improve program structure, performance, or other
    features.",
  usesDaikon = 1,
}


% My dissertation summary
@InProceedings{Ernst01:ICSM,
  author = 	 "Michael D. Ernst",
  title = 	 "Summary of {\em Dynamically discovering likely program invariants}",
  crossref =     "ICSM2001",
  pages = 	 "540--544",
  abstract =
   "The dissertation {\em Dynamically discovering likely program
    invariants}~\cite{Ernst2000:PhD} introduces dynamic detection of
    program invariants, presents techniques for detecting such invariants
    from traces, assesses the techniques' efficacy, and points the way for
    future research.
    \par
    Invariants are valuable in many aspects of program development, including
    design, coding, verification, testing, optimization, and maintenance.
    They also enhance programmers' understanding of data structures,
    algorithms, and program operation.  Unfortunately, explicit invariants
    are usually absent from programs, depriving programmers and automated
    tools of their benefits.
    \par
    The dissertation shows how invariants can be dynamically detected from
    program traces that capture variable values at program points of
    interest.  The user runs the target program over a test suite to create
    the traces, and an invariant detector determines which properties and
    relationships hold over both explicit variables and other expressions.
    Properties that hold over the traces and also satisfy other tests, such
    as being statistically justified, not being over unrelated variables, and
    not being implied by other reported invariants, are reported as likely
    invariants.  Like other dynamic techniques such as testing, the quality
    of the output depends in part on the comprehensiveness of the test suite.
    If the test suite is inadequate, then the output indicates how,
    permitting its improvement.  Dynamic analysis complements static
    techniques, which can be made sound but for which certain program
    constructs remain beyond the state of the art.
    \par
    Experiments demonstrate a number of positive qualities of dynamic
    invariant detection and of a prototype implementation, Daikon.  Invariant
    detection is accurate{\,---\,}it rediscovers formal
    specifications{\,---\,}and useful{\,---\,}it assists programmers in
    programming tasks.  It runs quickly and produces output of modest size.
    Test suites found in practice tend to be adequate for dynamic invariant
    detection.",
  supersededby = "Ernst2000:PhD A summary",
}


@Manual{DaikonManual-2.3.2,
  title = 	 "The Daikon Invariant Detector User Manual",
  key = 	 "Daikon",
  OPTauthor = 	 "Michael D. Ernst",
  month = 	 dec # "~7,",
  year = 	 2001,
  note = 	 "Version 2.3.2. \url{https://plse.cs.washington.edu/daikon/}",
  omitfromcv =   1,
}

@Manual{DaikonManual-2.3.1,
  title = 	 "The Daikon Invariant Detector User Manual",
  key = 	 "Daikon",
  month = 	 oct # "~8,",
  year = 	 2001,
  note = 	 "Version 2.3.1. \url{https://plse.cs.washington.edu/daikon/}",
  omitfromcv =   1,
}

@Manual{DaikonManual-4.5.0,
  title = 	 "The Daikon Invariant Detector User Manual",
  key = 	 "Daikon",
  month = 	 sep # "~3,",
  year = 	 2008,
  note = 	 "Version 4.5.0. \url{https://plse.cs.washington.edu/daikon/}",
  omitfromcv =   1,
}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%% 2002
%%%

@TechReport{NimmerE01:specs-TR823,
  author = 	 "Jeremy W. Nimmer and Michael D. Ernst",
  title = 	 "Automatic generation and checking of program specifications",
  institution =  MITLCS,
  year = 	 2001,
  number = 	 823,
  address = 	 MITaddr,
  month = 	 aug # "~10,",
  note =         "Revised " # feb # "~1, 2002",
  abstract =
   "Producing specifications by dynamic (runtime) analysis of program
    executions is potentially unsound, because the analyzed executions may
    not fully characterize all possible executions of the program.  In
    practice, how accurate are the results of a dynamic analysis?  This
    paper describes the results of an investigation into this question,
    determining how much specifications generalized from program runs must
    be changed in order to be verified by a static checker.  Surprisingly,
    small test suites captured nearly all program behavior required by a
    specific type of static checking; the static checker guaranteed the
    correctness of the generated specifications and the absence of runtime
    exceptions.  Measured against this verification task, the generated
    specifications scored approximately 90\% on precision, a measure of
    correctness, and on recall, a measure of completeness.
    \par
    This is a positive result for testing, because it suggests that dynamic
    analyses can capture all semantic information of interest for certain
    applications.  The experimental results demonstrate that a specific
    technique, dynamic invariant detection, is effective at generating
    consistent, sufficient specifications.  Finally, the research shows
    that combining static and dynamic analyses over program specifications
    has benefits for users of each technique, guaranteeing correctness of
    the dynamic analysis and lessening the annotation burden for users of
    the static analysis.",
  basefilename = "invariants-specs-tr823",
  supersededby = "NimmerE02:ISSTA",
  undergradCoauthor = 1,
}


@InProceedings{NimmerE02:ISSTA,
  author = 	 "Jeremy W. Nimmer and Michael D. Ernst",
  title = 	 "Automatic generation of program specifications",
  crossref =     "ISSTA2002",
  pages = 	 "232--242",
  abstract =
   "Producing specifications by dynamic (runtime) analysis of program
    executions is potentially unsound, because the analyzed executions may
    not fully characterize all possible executions of the program.  In
    practice, how accurate are the results of a dynamic analysis?  This
    paper describes the results of an investigation into this question,
    determining how much specifications generalized from program runs must
    be changed in order to be verified by a static checker.  Surprisingly,
    small test suites captured nearly all program behavior required by a
    specific type of static checking; the static checker guaranteed that
    the implementations satisfy the generated specifications, and ensured
    the absence of runtime exceptions.  Measured against this verification
    task, the generated specifications scored over 90\% on
    precision, a measure of soundness, and on recall, a measure of
    completeness.
    \par
    This is a positive result for testing, because it suggests that dynamic
    analyses can capture all semantic information of interest for certain
    applications.  The experimental results demonstrate that a specific
    technique, dynamic invariant detection, is effective at generating
    consistent, sufficient specifications for use by a static checker.
    Finally, the research shows that combining static and dynamic analyses
    over program specifications has benefits for users of each technique,
    guaranteeing soundness of the dynamic analysis and lessening the
    annotation burden for users of the static analysis.",
  basefilename = "generate-specs-issta2002",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/generate-specs-issta2002.pdf PDF",
  category = "Specification inference,Verification",
  csetags = "mernst,mernst-Verification,plse",
  summary =
   "Sound program verifiers generally require program specifications, which
    are tedious and difficult to generate.  A dynamic analysis can
    automatically produce unsound specifications.  Combining the two
    techniques overcomes both weaknesses and demonstrates that the dynamic
    step, while unsound, can be quite accurate in practice.",
  usesDaikon = 1,
  undergradCoauthor = 1,
}

% Used to be named NimmerE02:annotate
@InProceedings{NimmerE02:FSE,
  author =	 "Jeremy W. Nimmer and Michael D. Ernst",
  title =	 "Invariant inference for static checking: An empirical evaluation",
  crossref =     "FSE2002",
  pages = 	 "11--20",
  basefilename = "annotation-study-fse2002",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/annotation-study-fse2002.pdf PDF",
  abstract =
   "Static checking can verify the absence of errors in a program, but often
    requires written annotations or specifications.  As a result, static
    checking can be difficult to use effectively: it can be difficult to
    determine a specification and tedious to annotate programs.  Automated
    tools that aid the annotation process can decrease the cost of static
    checking and enable it to be more widely used.
    \par
    This paper describes an evaluation of the effectiveness of two techniques,
    one static and one dynamic, to assist the annotation process.
    We quantitatively and qualitatively evaluate 41 programmers using ESC/Java
    in a program verification task over three small programs, using Houdini
    for static inference and Daikon for dynamic inference.
    We also investigate the effect of unsoundness in the dynamic analysis.
    \par
    Statistically significant results show that
     both inference tools improve task completion;
     Daikon enables users to express more correct invariants;
     unsoundness of the dynamic analysis is little hindrance to users; and
     users imperfectly exploit Houdini.
    Interviews indicate
    that beginning users found Daikon to be helpful; Houdini to be neutral;
    static checking to be of potential practical use; and both assistance
    tools to have unique benefits.
    \par
    Our observations not only provide a critical evaluation of these two
    techniques, but also highlight important considerations for
    creating future assistance tools.",
  category = "Specification inference,Verification",
  csetags = "mernst,mernst-Verification,plse",
  summary =
   "Tool unsoundness and incompleteness may hinder users performing a task,
    or users may benefit even from imperfect output.  In a
    study of program verification aided by dynamic invariant detection,
    even very poor output from the invariant detector aided users to a
    statistically significant degree.",
  usesDaikon = 1,
  undergradCoauthor = 1,
}


@Misc{DodooDLE02,
  author =	 "Nii Dodoo and Alan Donovan and Lee Lin and Michael D. Ernst",
  title =	 "Selecting predicates for implications in program analysis",
  month =	 mar # "~16,",
  year =	 2002,
  OLDnote =         "Draft.  \url{https://homes.cs.washington.edu/~mernst/pubs/invariants-implications.ps}",
  NOTEaboutsupersededby = "Donovan isn't an author on the superseding
    publication; an interesting special case for programs processing this file.",
  supersededby = "DodooLE2003:TR",
  NOTEaboutbasefilename = "This is a well-known URL; do not change basefilename",
  basefilename = "invariants-implications",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/invariants-implications.pdf PDF",
  abstract =
   "This research proposes and evaluates techniques for selecting predicates
    for conditional program properties{\,---\,}that is, implications such as $p
    \Rightarrow q$ whose consequent is true only when the predicate is true.
    Conditional properties are prevalent in recursive data structures, which
    behave differently in their base and recursive cases, and in many other
    situations.  The experimental context of the research is dynamic detection
    of likely program invariants, but the ideas should also be applicable to
    other domains.
    \par
    It is computationally infeasible to try every possible predicate for
    conditional properties, so we compare procedure return analysis, static
    analysis, clustering, random selection, and context-sensitive analysis for
    selecting predicates.
    \par
    Even a simple static analysis is fairly effective, presumably because many
    of the important properties of a program are tested or expressed by
    programmers.  However, important properties are implicit in the program's
    code or execution.  We give examples of important properties discovered by
    each of the other analyses.  We experimentally evaluate the techniques on
    two tasks:  statically proving the absence of run-time errors with a
    theorem-prover, and detecting errors by separating erroneous from correct
    executions.  We show that the techniques improve performance on both tasks,
    and we evaluate their costs.",
  alsosee = "Dodoo02:thesis",
  category = "Static analysis",
  csetags = "mernst,mernst-Static-analysis,plse",
  summary =
   "Many program analyses need to produce conditional properties or
    implications of the form $p \Rightarrow q$, because often properties of
    interest do not hold universally.  This paper evaluates the efficacy of
    several techniques for selecting the predicates $p$.  These techniques
    permit the examination of a subset of the many potential implications.",
  usesDaikon = 1,
  undergradCoauthor = 1,
}


% Old key was NeWinEL02; actual second author is "Michael Ernst".
@TechReport{NeWinE02:TR841,
  author = 	 "Toh {Ne Win} and Michael D. Ernst",
  title = 	 "Verifying distributed algorithms via dynamic analysis and theorem proving",
  institution =  MITLCS,
  year = 	 2002,
  number = 	 841,
  address = 	 MITaddr,
  month = 	 may # "~25,",
  abstract =
   "We use output from dynamic analysis to assist theorem-proving of safety
    properties of distributed algorithms.  The algorithms are written in the
    IOA language, which is based on the mathematical I/O automaton model.
    Daikon, a dynamic invariant discovery tool, generalizes from test
    executions, producing assertions about the observed behavior of the
    algorithm.
    \par
    We use these relatively simple run-time properties as lemmas in proving
    program properties.  These lemmas are necessary, but easy for humans to
    overlook.  Furthermore, the lemmas decompose complex steps into simple ones
    that theorem provers can manage mostly unassisted, thus reducing the human
    effort required to prove interesting algorithm properties.
    \par
    In several experiments, Daikon produced all or most of the lemmas required
    for correctness proofs, automating the most difficult part of the process,
    which usually requires human insight.
    \par
    This verification technique is a worthwhile alternative to using only
    static analysis with model checkers or theorem provers, or only dynamic
    analysis with simulators and runtime analyzers.  Our technique combines the
    advantages of static and dynamic analysis: it is sound and scales to
    algorithms with unbounded processes and variable sizes.  Further, it can
    suggest and verify new program properties that the designer might not have
    envisioned.",
  supersededby = "NeWinEGKL03:VMCAI Additional details and case studies",
  basefilename = "verify-distributed-tr841",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/verify-distributed-tr841.pdf PDF",
  category = "Distributed systems,Verification",
  csetags = "mernst,mernst-Verification,plse",
  summary =
   "Automatic theorem-provers require human direction in the form of lemmas
    and invariants.  We investigate a dynamic technique for providing these
    intermediate steps.  In three case studies, they reduced or eliminated
    human effort.",
  usesDaikon = 1,
  undergradCoauthor = 1,
}


@Article{WilmerE02,
  author = 	 "Elizabeth L. Wilmer and Michael D. Ernst",
  title = 	 "Graphs induced by {Gray} codes",
  journal = 	 "Discrete Mathematics",
  year =	 2002,
  volume =	 257,
  pages = 	 "585--598",
  month = 	 nov # "~28,",
  abstract =
     "We disprove a conjecture of Bultena and Ruskey
      (Electron. J. Combin. 3 (1996) R11),
      that all trees which are cyclic graphs of cyclic Gray codes have
      diameter~2 or~4, by producing codes whose cyclic graphs are
      trees of arbitrarily large diameter. We answer affirmatively two
      other questions from (Electron. J. Combin. 3 (1996) R11),
      showing that strongly $(P_n
      \times P_n)$-compatible codes exist and that it is possible for a
      cyclic code to induce a cyclic digraph with no bidirectional
      edge.
      \par
      A major tool in these proofs is our introduction  of
      \textit{supercomposite} Gray codes; these generalize the
      standard reflected Gray code by allowing shifts. We find
      supercomposite Gray codes which induce large diameter trees, but
      also show that many trees are not induced by supercomposite Gray
      codes.
      \par
      We also find the first infinite family of connected graphs known
      not to be induced by any Gray code---trees of diameter~3 with
      no vertices of degree~2.",
  basefilename = "graycodes-dm2002",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/graycodes-dm2002.pdf PDF",
  category = "Theory",
  csetags = "mernst,mernst-Theory,plse",
  summary =
   "A Gray code on {\em n} bits induces a graph over {\em n} vertices such
    that vertices {\em i} and {\em j} are adjacent when bit positions {\em
    i} and {\em j} flip consecutively during the code.  This paper answers
    some questions about what sorts of graphs can (and cannot) be induced
    by Gray codes.",
  nonPAG = 1,
}


@Article{ErnstBN2002:TSE,
  author = 	 "Michael D. Ernst and Greg J. Badros and David Notkin",
  title = 	 "An empirical analysis of {C} preprocessor use",
  journal = 	 IEEETSE,
  year = 	 2002,
  volume = 	 28,
  number = 	 12,
  pages = 	 "1146--1170",
  month = 	 dec,
  basefilename = "c-preprocessor-tse2002",
  downloads =
   "https://homes.cs.washington.edu/~mernst/pubs/macros.tar.gz implementation",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/c-preprocessor-tse2002.pdf PDF",
  abstract =
   "This is the first empirical study of the use of the C macro preprocessor,
    Cpp.  To determine how the preprocessor is used in practice, this paper
    analyzes 26 packages comprising 1.4 million lines of
    publicly available C code.  We determine the incidence of C preprocessor
    usage\,---\,whether in macro definitions, macro uses, or dependences upon
    macros\,---\,that is complex, potentially problematic, or inexpressible
    in terms of other C or C++ language features.  We taxonomize these
    various aspects of preprocessor use and particularly note data that are
    material to the development of tools for C or C++, including translating
    from C to C++ to reduce preprocessor usage.  Our results show that while
    most Cpp usage follows fairly simple patterns, an effective program
    analysis tool must address the preprocessor.
    \par
    The intimate connection between the C programming language and Cpp, and
    Cpp's unstructured transformations of token streams, often hinder
    programmer understanding of C programs and tools built to engineer C
    programs, such as compilers, debuggers, call graph extractors, and
    translators.  Most tools make no attempt to analyze macro usage, but
    simply preprocess their input, which results in a number of negative
    consequences; an analysis that takes Cpp into account is preferable, but
    building such tools requires an understanding of actual usage.
    Differences between the semantics of Cpp and those of C can lead to
    subtle bugs stemming from the use of the preprocessor, but there are no
    previous reports of the prevalence of such errors.  Use of C++ can reduce
    some preprocessor usage, but such usage has not been previously measured.
    Our data and analyses shed light on these issues and others related to
    practical understanding or manipulation of real C programs.  The results
    are of interest to language designers, tool writers, programmers, and
    software engineers.",
  category = "Programming language design",
  csetags = "mernst,notkin,mernst-Static-analysis,plse",
  summary =
   "Undisciplined use of the C preprocessor can greatly hinder program
    understanding and manipulation.  This paper examines 1.2 million lines
    of C code to determine what types of problematic uses appear in practice.",
}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%% 2003
%%%


@InProceedings{WilmerE03:ALICE,
  author = 	 "Elizabeth L. Wilmer and Michael D. Ernst",
  title = 	 "Graphs induced by {Gray} codes",
  booktitle =	 "ALICE03, 1st Workshop on Algorithms for Listing,
                  Counting, and Enumeration",
  OPTpages = 	 "",
  year =	 2003,
  address =	 "Baltimore, Maryland",
  month =	 jan # "~11,",
  supersededby = "WilmerE02",
  nonPAG = 1,
}


@InProceedings{NeWinEGKL03:VMCAI,
  author = 	 "Toh {Ne Win} and Michael D. Ernst and Stephen J. Garland and Dilsun K{\i}rl{\i} and Nancy Lynch",
  authorASCII = 	 "Toh Ne Win and Michael D. Ernst and Stephen J. Garland and Dilsun Kirli and Nancy Lynch",
  title = 	 "Using simulated execution in verifying distributed algorithms",
  crossref =     "VMCAI2003",
  pages =	 "283--297",
  abstract =
   "This paper presents a methodology for using simulated execution to
    assist a theorem prover in verifying safety properties of distributed
    systems.  Execution-based techniques such as testing can increase
    confidence in an implementation, provide intuition about behavior, and
    detect simple errors quickly.  They cannot by themselves demonstrate
    correctness.  However, they can aid theorem provers by suggesting
    necessary lemmas and providing tactics to structure proofs.  This
    paper describes the use of these techniques in a machine-checked proof
    of correctness of the Paxos algorithm for distributed consensus.",
  supersededby = "NeWinEGKL04:STTT",
  basefilename = "simexecution-vmcai2003",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/simexecution-vmcai2003.pdf PDF",
  category = "Distributed systems,Verification",
  csetags = "mernst,mernst-Verification,plse",
  summary =
   "This paper proposes integration of dynamic analysis with traditional
    theorem-proving in ways that extend beyond mere testing.  Generalizing
    over the test runs can reveal necessary lemmas, and the structure of
    the proof can mirror the structure of the execution.",
  usesDaikon = 1,
  undergradCoauthor = 1,
}


@InProceedings{HarderME03,
  author = 	 "Michael Harder and Jeff Mellen and Michael D. Ernst",
  title = 	 "Improving test suites via operational abstraction",
  crossref =     "ICSE2003",
  pages =	 "60--71",
  abstract =
   "This paper presents the operational difference technique for generating,
    augmenting, and minimizing test suites.  The technique is analogous to
    structural code coverage techniques, but it operates in the semantic domain
    of program properties rather than the syntactic domain of program text.
    \par
    The operational difference technique automatically selects test cases; it
    assumes only the existence of a source of test cases.  The technique
    dynamically generates operational abstractions (which describe observed
    behavior and are syntactically identical to formal specifications) from
    test suite executions.  Test suites can be generated by adding cases until
    the operational abstraction stops changing.  The resulting test suites are
    as small, and detect as many faults, as suites with 100\% branch coverage,
    and are better at detecting certain common faults.
    \par
    This paper also presents the area and stacking techniques for comparing
    test suite generation strategies; these techniques avoid bias due to test
    suite size.",
  basefilename = "improve-testsuite-icse2003",
  alsosee = "Harder02:TR",
  category = "Test generation",
  csetags = "mernst,mernst-Testing,plse",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/improve-testsuite-icse2003.pdf PDF",
  downloads =
   "https://homes.cs.washington.edu/~mernst/pubs/improve-testsuite-slides.pdf talk slides (PDF);
    https://homes.cs.washington.edu/~mernst/pubs/improve-testsuite-slides.ppt talk slides (PowerPoint)",
  summary =
   "This paper proposes a technique for selecting test cases that is
    similar to structural code coverage techniques, but operates in the
    semantic domain of program behavior rather than in the lexical domain
    of program text.  The technique outperforms branch coverage in test suite
    size and in fault detection.",
  usesDaikon = 1,
  undergradCoauthor = 1,
}


@TechReport{DonovanE03:TR,
  author = 	 "Alan Donovan and Michael D. Ernst",
  title = 	 "Inference of generic types in {Java}",
  institution =  MITLCS,
  year = 	 2003,
  number =	 "MIT/LCS/TR-889",
  address =	 MITaddr,
  month =	 mar # "~22,",
  supersededby = "DonovanKTE2004",
  basefilename = "infer-generic-tr889",
  category = "Refactoring",
  OMITcsetagsBECAUSESUPERSEDED = "mernst,mernst-Static-analysis,plse",
  summary =
   "This paper shows how to add parametric polymorphism to a program by
    determining the proper parameterisation for the implementation of an ADT
    and determining the proper instantiation at clients (uses) of the ADT.",
  abstract =
   "Future versions of Java will include support for {\it parametric
    polymorphism}, or {\it generic} classes.  This will bring many benefits
    to Java programmers, not least because current Java practise makes heavy
    use of {\it pseudo}-generic classes.  Such classes (for example, those in
    package {\tt java.util}) have logically generic specifications and
    documentation, but the type system cannot prove their patterns of use to be
    safe.
    \par
    This work aims to solve the problem of automatic translation of Java source
    code into Generic Java (GJ) source code.  We present two algorithms that
    together can be used to translate automatically a Java source program into
    a semantically-equivalent GJ program with generic types.
    \par
    The first algorithm infers a candidate generalisation for any class, based
    on the methods of that class in isolation.  The second algorithm analyses
    the whole program; it determines a precise parametric type for every value
    in the program.  Optionally, it also refines the generalisations produced
    by the first analysis as required by the patterns of use of those classes
    in client code.",
}

% Actual fourth author is "Michael Ernst" (but that's fixed in the
% BurdyEtAl03 paper).
@TechReport{BurdyEtAl03:TR,
  author =       {Lilian Burdy and Yoonsik Cheon and David Cok and
		   Michael D. Ernst and Joe Kiniry and Gary T. Leavens and
		   K. Rustan M. Leino and Erik Poll},
  title =        {An overview of {JML} tools and applications},
  institution =  {University of Nijmegen Dept. of Computer Science},
  year =         2003,
  month =        mar,
  number =       {NIII-R0309},
  supersededby = "BurdyEtAl03",
  basefilename = "jml-tools-trr0309",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/jml-tools-trr0309.pdf PDF",
  category = "Verification",
  OMITcsetagsBECAUSESUPERSEDED = "mernst,mernst-Verification,plse",
  summary =
   "This paper overviews the Java Modeling Language (JML) notation for
    detailed design and gives a brief description of some of the tools that
    take it as an input or produce it as an output.",
  abstract =
   "The Java Modeling Language (JML) can be used to specify the detailed design
    of Java classes and interfaces by adding annotations to Java source
    files. The aim of JML is to provide a specification language that is easy
    to use for Java programmers and that is supported by a wide range of tools
    for specification type-checking, runtime debugging, static analysis, and
    verification.
    \par
    This paper gives an overview of the main ideas behind JML, the different
    groups collaborating to provide tools for JML, and the existing
    applications of JML. Thus far, most applications have focused on code for
    programming smartcards written in the Java Card dialect of Java.",
}


@InProceedings{Ernst2003:WODA,
  author = 	 "Michael D. Ernst",
  title = 	 "Static and dynamic analysis:  Synergy and duality",
  crossref =     "WODA2003",
  pages =	 "24--27",
  OMITeditor =	 "Jonathan E. Cook and Michael D. Ernst",
  basefilename = "staticdynamic-woda2003",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/staticdynamic-woda2003.pdf PDF",
  downloads =
   "https://homes.cs.washington.edu/~mernst/pubs/staticdynamic-paste2004-slides-dist.pdf slides (PDF);
    https://homes.cs.washington.edu/~mernst/pubs/staticdynamic-paste2004-slides-dist.ppt slides (PowerPoint)",
  category = "Dynamic analysis",
  csetags = "mernst,mernst-Dynamic-analysis,plse",
  summary =
   "This position paper is intended to provoke thought and discussion
    regarding the relationship between static and dynamic analysis.  The paper
    claims they are not as different as many have assumed.",
  abstract =
   "This paper presents two sets of observations relating static and dynamic
    analysis.  The first concerns synergies between static and dynamic
    analysis.  Wherever one is utilized, the other may also be applied, often
    in a complementary way, and existing analyses should inspire different
    approaches to the same problem.  Furthermore, existing static and dynamic
    analyses often have very similar structure and technical approaches.
    The second observation is that some static and dynamic approaches are
    similar in that each considers, and generalizes from, a subset of all
    possible executions.
    \par
    Researchers need to develop new analyses that complement existing ones.
    More importantly, researchers need to erase the boundaries between static
    and dynamic analysis and create unified analyses that can operate in
    either mode, or in a mode that blends the strengths of both approaches.",
}


@Proceedings{WODA2003:proc,
  title = 	 "WODA 2003: ICSE Workshop on Dynamic Analysis",
  year = 	 2003,
  editor =	 "Jonathan E. Cook and Michael D. Ernst",
  address =	 "Portland, Oregon",
  month =	 may,
  basefilename = "woda2003-proceedings",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/woda2003-proceedings.pdf PDF",
  downloads =    "https://www.cs.nmsu.edu/~jcook/woda2003/ workshop website",
  category = "Dynamic analysis",
  csetags = "mernst,mernst-Dynamic-analysis,plse",
  summary =
   "This workshop brought together practitioners and academics to discuss
    topics from the structure of the dynamic analysis field, to how to
    enable better and easier progress, to specific new analysis ideas.",
  abstract =
   "Dynamic analysis techniques reason over the run-time behavior of
    systems. Dynamic analysis includes both offline techniques that operate on
    a trace of the system's behavior, and online techniques that operate while
    the system is producing its behavior. Examples of dynamic analysis
    techniques are profilers, memory allocation monitors, and assertion
    checkers. Themes and needs shared by all dynamic analysis techniques
    include:
    \begin{enumerate}
      \item instrumentation;
      \item data collection, description, and management;
      \item behavior descriptions;
      \item partial and/or noisy information; and
      \item reasoning with partial models.
    \end{enumerate}
    \par
    WODA 2003 aims to bring together researchers working on topics related to
    dynamic analysis and runtime monitoring. Doing so will help create synergy
    and understanding within this community of researchers, and will improve
    the progress of the field by exposing participants to new ideas and to
    potential collaborators.
    \par
    This workshop will focus on achieving a consensus among the participants as
    to the structure of the field, the important research directions this field
    should take, inputs needed from other research domains, and outputs that
    could benefit other research domains. It will cover a topical spectrum
    possibly including:
    \begin{enumerate}
      \item enabling technologies;
      \item framework and common tool support;
      \item event type definition, classification, and specification;
      \item symbolic and theoretically exact reasoning techniques;
      \item statistical and probabilistic reasoning techniques;
      \item research foundations;
      \item relationships to static analysis;
      \item relationships to testing; and
      \item other potential topics.
    \end{enumerate}
    \par
    This workshop will be a one-day workshop. Potential participants should to
    submit a position paper of up to four (4) pages on one or more of the
    relevant sub-topics. It should not be a description of a specific research
    activity, but rather an insight into the problems, needs, or approaches
    that researchers in dynamic analysis can use to further their understanding
    of the area. Each accepted position paper must have at least one author in
    attendance at the workshop. Those who have not submitted a position paper
    may attend if there are available slots after authors have registered; but
    all participants are encouraged to prepare their thoughts, opinions, and
    insights regarding the present and future of dynamic analysis.
    \par
    About ICSE: The International Conference on Software Engineering (ICSE) is
    the premier software engineering conference. It provides a forum for
    researchers, practitioners, and educators to present and discuss the most
    recent advances, trends, and concerns. Workshops have been an important
    part of this role, and we are pleased to offer the Workshop on Dynamic
    Analysis (WODA 2003) at ICSE 2003.",
}


@Article{WODA2003:summary,
  author = 	 "Jonathan E. Cook and Michael D. Ernst",
  title = 	 "Summary: Workshop on Dynamic Analysis (WODA 2003)",
  journal = 	 SEN,
  year = 	 2003,
  volume =	 28,
  number =	 6,
  pages =	 27,
  month =	 nov,
  abstract =
   "Dynamic analysis of software systems has long proven to be a
    practical approach to gain understanding of the operational
    behavior of the system. This workshop will bring together researchers
    in the field of dynamic analysis to discuss the breadth of the
    field, order the field along logical dimensions, expose common
    issues and approaches, and stimulate synergistic collaborations
    among the participants.",
  basefilename = "woda2003-summary",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/woda2003-summary.pdf PDF",
  category = "Dynamic analysis",
  csetags = "mernst,mernst-Dynamic-analysis,plse",
  summary =
   "This summary recaps the WODA 2003 workshop.  WODA brought together
    practitioners and academics to discuss topics from the structure of the
    dynamic analysis field, to how to enable better and easier progress, to
    specific new analysis ideas.",
  supersededby = "WODA2003:proc A summary"
}


@Misc{MeghaniE2003,
  author = 	 "Samir V. Meghani and Michael D. Ernst",
  title = 	 "Determining legal method call sequences in object interfaces",
  month = 	 may,
  year = 	 2003,
  howpublished = "\url{https://homes.cs.washington.edu/~mernst/pubs/call-sequences.pdf}",
  abstract =
   "The permitted sequences of method calls in an object-oriented component
    interface summarize how to correctly use the component.  Many components
    lack such documentation: even if the documentation specifies the behavior
    of each of the component's methods, it may not state the order in which the
    methods should be invoked.  This paper presents a dynamic technique for
    automatically extracting the legal method call sequences in a component
    interface, expressed as a finite state machine.  Compared to previous
    techniques, it increases accuracy and reduces dependence on the test suite.
    It also identifies certain programming errors.",
  basefilename = "call-sequences",
  downloads = "https://homes.cs.washington.edu/~mernst/pubs/call-sequences.pdf PDF",
  category = "Specification inference",
  csetags = "mernst,mernst-Invariant-detection,plse",
  summary =
   "Correct functioning of a component can depend on the component's methods
    being called in the correct order.  This paper simplifies and improves on
    previous techniques for determining the legal call sequences.",
  usesDaikon = 1,
  undergradCoauthor = 1,
}


@InProceedings{BurdyEtAl03,
  author =       {Lilian Burdy and Yoonsik Cheon and David Cok and
		   Michael D. Ernst and Joe Kiniry and Gary T. Leavens and
		   K. Rustan M. Leino and Erik Poll},
  title =        {An overview of {JML} tools and applications},
  crossref =     "FMICS03",
  supersededby = "BurdyCCEKLLP2005",
  basefilename = "jml-tools-fmics2003",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/jml-tools-fmics2003.pdf PDF",
  category = "Verification",
  OMITcsetagsBECAUSESUPERSEDED = "mernst,mernst-Verification,plse",
  summary =
   "This paper overviews the Java Modeling Language (JML) notation for
    detailed design and gives a brief description of some of the tools that
    take it as an input or produce it as an output.",
  abstract =
   "The Java Modeling Language (JML) can be used to specify the detailed design
    of Java classes and interfaces by adding annotations to Java source
    files. The aim of JML is to provide a specification language that is easy
    to use for Java programmers and that is supported by a wide range of tools
    for specification type-checking, runtime debugging, static analysis, and
    verification.
    \par
    This paper gives an overview of the main ideas behind JML, the different
    groups collaborating to provide tools for JML, and the existing
    applications of JML. Thus far, most applications have focused on code for
    programming smartcards written in the Java Card dialect of Java.",
}


@InProceedings{McCamantE2003,
  author = 	 "Stephen McCamant and Michael D. Ernst",
  title = 	 "Predicting problems caused by component upgrades",
  crossref =     "FSE2003",
  pages = 	 "287--296",
  basefilename = "upgrades-fse2003",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/upgrades-fse2003.pdf PDF",
  category = "Defect prediction",
  csetags = "mernst,mernst-Bug-prediction,plse",
  summary =
   "A software upgrade may break a customer's system because of differences
    between it and the vendor's test environment.  This paper shows how to
    predict such problems without having to integrate and test.",
  abstract =
   "We present a new, automatic technique to assess whether replacing
    a component of a software system by a purportedly compatible
    component may change the behavior of the system.  The technique
    operates before integrating the new component into the system or
    running system tests, permitting quicker and cheaper
    identification of problems.  It takes into account the system's
    use of the component, because a particular component upgrade may
    be desirable in one context but undesirable in another.  No
    formal specifications are required, permitting detection of
    problems due either to errors in the component or to errors in
    the system.  Both external and internal behaviors can be
    compared, enabling detection of problems that are not immediately
    reflected in the output.
    \par
    The technique generates an operational abstraction for the old
    component in the context of the system and generates an
    operational abstraction for the new component in the context of
    its test suite; an operational abstraction is a set of program
    properties that generalizes over observed run-time behavior.  If
    automated logical comparison indicates that the new component
    does not make all the guarantees that the old one did, then the
    upgrade may affect system behavior and should not be performed
    without further scrutiny.  In case studies, the technique
    identified several incompatibilities among software components.",
  usesDaikon = 1,
}


@TechReport{DodooLE2003:TR,
  author = 	 "Nii Dodoo and Lee Lin and Michael D. Ernst",
  pseudoauthor = "Alan Donovan",
  title = 	 "Selecting, refining, and evaluating predicates for program analysis",
  institution =  MITLCS,
  year = 	 2003,
  number =	 "MIT-LCS-TR-914",
  address =	 MITaddr,
  month =	 jul # "~21,",
  abstract =
   "This research proposes and evaluates techniques for selecting predicates
    for conditional program properties{\,---\,}that is, implications such as $p
    \Rightarrow q$ whose consequent must be true whenever the predicate is true.
    Conditional properties are prevalent in recursive data structures,
    which behave differently in their base and recursive cases, in
    programs that contain branches, in programs that fail only on some
    inputs, and in many other situations.  The experimental context of the
    research is dynamic detection of likely program invariants, but the
    ideas are applicable to other domains.
    \par
    Trying every possible predicate for conditional properties is
    computationally infeasible and yields too many undesirable properties.
    This paper compares four policies for selecting predicates: procedure
    return analysis, code conditionals, clustering, and random selection.
    It also shows how to improve predicates via iterated analysis.  An
    experimental evaluation demonstrates that the techniques improve
    performance on two tasks: statically proving the absence of run-time
    errors with a theorem-prover, and separating faulty from correct
    executions of erroneous programs.",
  category = "Static analysis",
  csetags = "mernst,mernst-Static-analysis,plse",
  basefilename = "predicates-tr914",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/predicates-tr914.pdf PDF",
  summary =
   "This paper investigates several techniques, notably dynamic ones based
    on random selection and machine learning, for predicate abstraction ---
    selecting the predicates that are most effective for a program analysis.",
  usesDaikon = 1,
  undergradCoauthor = 1,
}


@InProceedings{SaffE2003,
  author = 	 "David Saff and Michael D. Ernst",
  title = 	 "Reducing wasted development time via continuous testing",
  crossref =     "ISSRE2003",
  pages = 	 "281--292",
  abstract =
   "Testing is often performed frequently during development to ensure software
    reliability by catching regression errors quickly.  However, stopping
    frequently to test also wastes time by holding up
    development progress.  User studies on real development projects
    indicate that these two sources of wasted time account for 10--15\%
    of development time.  These measurements use a novel
    technique for computing the wasted extra development time incurred by
    a delay in discovering a regression error.
    \par
    We present a model of developer behavior that infers developer beliefs
    from developer behavior, and that predicts developer behavior in new
    environments{\,---\,}in particular, when changing testing
    methodologies or tools to reduce wasted time.  Changing test ordering
    or reporting reduces wasted time by 4--41\% in our case study.
    Changing the frequency with which tests are run can reduce wasted time
    by 31--82\% (but developers cannot know the ideal frequency except
    after the fact).  We introduce and evaluate a new technique,
    \emph{continuous testing}, that uses spare CPU resources to
    continuously run tests in the background, providing rapid feedback
    about test failures as source code is edited.  Continuous testing
    reduced wasted time by 92--98\%, a substantial improvement over the
    other approaches.
    \par
    We have integrated continuous testing into two development
    environments, and are beginning user studies to evaluate its efficacy.
    We believe it has the potential to reduce the cost and improve the
    efficacy of testing and, as a result, to improve the reliability of
    delivered systems.",
  category = "Testing",
  csetags = "mernst,mernst-Testing,plse",
  basefilename = "wasted-time-issre2003",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/wasted-time-issre2003.pdf PDF",
  summary =
   "Early notification of problems enables cheaper fixes.  This paper
    evaluates how much developer time could be saved by continuous testing,
    which uses extra CPU cycles to continuously run tests in the background.",
}


@InProceedings{LinE2003,
  author =	 "Lee Lin and Michael D. Ernst",
  title =	 "Improving reliability and adaptability via program steering",
  crossref =     "ISSRESupplementary2003",
  pages = 	 "313--314",
  abstract =
   "Software systems often contain several discrete modes of operation and a
    mechanism for switching between modes.  Even when a multi-mode system has
    been tested by its developer, it may be unreliable in the field, because
    the developer cannot foresee and test for every possible scenario;
    unexpected situations in which the program fails or underperforms (for
    example, by choosing a non-optimal mode) are certain to arise.  This
    research mitigates such problems by creating adaptive modal programs that
    handle unanticipated scenarios by autonomously selecting an appropriate
    mode.
    \par
    The technique creates a new mode selector via machine learning by training
    on good behavior in anticipated situations.  The new controller can augment
    or replace the old one.  Preliminary experiments indicate that our
    technique can re-derive ideal controllers and can improve the reliability
    and performance of good ones.",
  supersededby = "LinE2004",
  basefilename = "steering-issre2003",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/steering-issre2003.pdf PDF",
  category = "Program repair",
  OMITcsetagsBECAUSESUPERSEDED = "mernst,mernst-Dynamic-analysis,plse",
  summary =
   "For software with distinct modes and a mode selector that chooses among
    them, this paper shows how to augment an existing selector with an
    automatically-generated one that may be more robust and reliable in
    unanticipated situations.",
  usesDaikon = 1,
  undergradCoauthor = 1,
}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%% 2004
%%%


@TechReport{McCamant2004:ThesisTR,
  author = 	 "Stephen McCamant and Michael D. Ernst",
  title = 	 "Predicting problems caused by component upgrades",
  institution =  MITLCS,
  year = 	 2004,
  number = 	 941,
  address = 	 MITaddr,
  month = 	 mar,
  note = "Revision of first author's Master's thesis",
  abstract =
   "This thesis presents a new, automatic technique to assess whether
    replacing a component of a software system by a purportedly compatible
    component may change the behavior of the system.
    The technique operates before integrating the new component into the
    system or running system tests, permitting quicker and cheaper
    identification of problems.
    It takes into account the system's use of the component, because a
    particular component upgrade may be desirable in one context but
    undesirable in another.
    No formal specifications are required, permitting detection of
    problems due either to errors in the component or to errors in the
    system.
    Both external and internal behaviors can be compared, enabling
    detection of problems that are not immediately reflected in the
    output.
    \par
    The technique generates an operational abstraction for the old
    component in the context of the system, and one for the new component
    in the context of its test suite.
    An operational abstraction is a set of program properties that
    generalizes over observed run-time behavior.
    Modeling a system as divided into modules, and taking into account the
    control and data flow between the modules, we formulate a logical
    condition to guarantee that the system's behavior is preserved across
    a component replacement.
    If automated logical comparison indicates that the new component does
    not make all the guarantees that the old one did, then the upgrade may
    affect system behavior and should not be performed without further
    scrutiny.
    \par
    We describe a practical implementation of the technique, incorporating
    enhancements to handle non-local state, non-determinism, and missing
    test suites, and to distinguish old from new incompatibilities.
    We evaluate the implementation in case studies using real-world
    systems, including the Linux C library and 48 Unix programs.
    Our implementation identified real incompatibilities among versions of
    the C library that affected some of the programs, and it approved the
    upgrades for other programs that were unaffected by the changes.",
  supersededby = "McCamantE2003 An extended version,
                  McCamantE2004 An extended version",
  basefilename = "upgrades-mccamant-tr941",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/upgrades-mccamant-tr941.pdf PDF",
  category = "Defect prediction",
  csetags = "mernst,mernst-Dynamic-analysis,plse",
  summary =
   "A software upgrade may break a customer's system because of differences
    between it and the vendor's test environment.  This thesis shows how to
    predict such problems without having to integrate and test.",
  usesDaikon = 1,
}


@TechReport{DonovanKTE2004:TR,
  author =	 "Alan Donovan and Adam Kie{\.z}un and Matthew S. Tschantz and Michael D. Ernst",
  authorASCII =  "Adam Kiezun",
  title =	 "Converting {Java} programs to use generic libraries",
  institution =  MITLCS,
  year = 	 2004,
  number =	 "MIT-LCS-TR-940",
  address =	 MITaddr,
  month =	 mar # "~30,",
  supersededby = "DonovanKTE2004",
  abstract =
   "Java 1.5 will include a type system (called JSR-14) that supports
    \emph{parametric polymorphism}, or \emph{generic} classes.  This will bring
    many benefits to Java programmers, not least because current Java practice
    makes heavy use of logically-generic classes, including container classes.
    \par
    Translation of Java source code into semantically equivalent JSR-14 source
    code requires two steps: parameterization (adding type parameters to class
    definitions) and instantiation (adding the type arguments at each use of a
    parameterized class).  Parameterization need be done only once for a class,
    whereas instantiation must be performed for each client, of which there are
    potentially many more.  Therefore, this work focuses on the instantiation
    problem.  We present a technique to determine sound and precise JSR-14
    types at each use of a class for which a generic type specification is
    available.  Our approach uses a precise and context-sensitive pointer
    analysis to determine possible types at allocation sites, and a
    set-constraint-based analysis (that incorporates guarded, or conditional,
    constraints) to choose consistent types for both allocation and declaration
    sites.  The technique handles all features of the JSR-14 type system,
    notably the raw types that provide backward compatibility.  We have
    implemented our analysis in a tool that automatically inserts type
    parameters into Java code, and we report its performance when applied to a
    number of real-world Java programs.",
  category = "Refactoring",
  OMITcsetagsBECAUSESUPERSEDED = "mernst,mernst-Refactoring,plse",
  summary =
   "When type parameters are added to library code, client code should be
    upgraded to supply parameters at each use of library classes.  This
    paper presents a sound and precise combined pointer and type-based
    analysis that does so.",
  undergradCoauthor = 1,
}



@InProceedings{SaffE2004:ETX,
  author = 	 "David Saff and Michael D. Ernst",
  title = 	 "Continuous testing in {Eclipse}",
  crossref =     "ETX2004",
  abstract =
   "Continuous testing uses excess cycles on a developer's workstation to
    continuously run regression tests in the background, providing rapid
    feedback about test failures as source code is edited.  It is intended to
    reduce the time and energy required to keep code well-tested, and to
    prevent regression errors from persisting uncaught for long periods of
    time.
    \par
    This paper reports on the design and implementation of a continuous testing
    feature for Java development in the Eclipse development environment.  Our
    challenge was to generate and display a new kind of feedback (asynchronous
    notification of test failures) in a way that effectively reuses Eclipse's
    extensible architecture and fits the expectations of Eclipse users without
    interfering with their current work habits.  We present the design
    principles we pursued in solving this challenge: present and future reuse,
    consistent experience, minimal distraction, and testability.  These
    principles, and how our plug-in and Eclipse succeeded and failed in
    accomplishing them, should be of interest to other Eclipse extenders
    looking to implement new kinds of developer feedback.
    \par
    The continuous testing plug-in is publicly available at
    \url{https://groups.csail.mit.edu/pag/continuoustesting/}.",
  basefilename = "conttest-plugin-etx2004",
  category = "Testing",
  csetags = "mernst,mernst-Testing,plse",
  downloads =    "https://groups.csail.mit.edu/pag/continuoustesting/ Eclipse plug-in",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/conttest-plugin-etx2004.pdf PDF",
  summary =
   "This paper describes the design principles, user interface,
    architecture, and implementation of a publicly-available continuous
    testing plug-in for the Eclipse development environment.",
}


@InProceedings{BrunE2004,
  author = 	 "Yuriy Brun and Michael D. Ernst",
  title = 	 "Finding latent code errors via machine learning over
                  program executions",
  crossref =     "ICSE2004",
  pages = 	 "480--490",
  abstract =
   "This paper proposes a technique for identifying program properties that
    indicate errors.  The technique generates machine learning models of
    program properties known to result from errors, and applies these models to
    program properties of user-written code to classify and rank properties
    that may lead the user to errors.  Given a set of properties produced by
    the program analysis, the technique selects a subset of properties that are
    most likely to reveal an error.
    \par
    An implementation, the Fault Invariant Classifier, demonstrates the
    efficacy of the technique.  The implementation uses dynamic invariant
    detection to generate program properties.  It uses support vector machine
    and decision tree learning tools to classify those properties.  In our
    experimental evaluation, the technique increases the relevance (the
    concentration of fault-revealing properties) by a factor of 50 on average
    for the C programs, and 4.8 for the Java programs.  Preliminary experience
    suggests that most of the fault-revealing properties do lead a programmer
    to an error.",
  category = "Defect prediction",
  csetags = "mernst,mernst-Bug-prediction,plse",
  basefilename = "machlearn-errors-icse2004",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/machlearn-errors-icse2004.pdf PDF;
    https://homes.cs.washington.edu/~mernst/pubs/machlearn-errors-icse2004-slides.pdf slides (PDF)",
  summary =
   "This paper shows the efficacy of a technique that performs machine
    learning over correct and incorrect programs, then uses the resulting
    models to identify latent errors in other programs.",
  usesDaikon = 1,
  undergradCoauthor = 1,
}


@InProceedings{SaffE2004:mock-creation,
  author = 	 "David Saff and Michael D. Ernst",
  title = 	 "Automatic mock object creation for test factoring",
  crossref =     "PASTE2004",
  pages = 	 "49--51",
  abstract =
   "{\em Test factoring} creates fast, focused unit tests from slow system-wide
    tests; each new unit test exercises only a subset of the functionality
    exercised by the system tests.  Augmenting a test suite with factored unit
    tests, and prioritizing the tests, should catch errors earlier in a test
    run.
    \par
    One way to factor a test is to introduce \emph{mock objects}.  If a test
    exercises a component A, which is designed to issue queries against or
    mutate another component B, the implementation of B can be replaced by a
    {\em mock}.  The mock has two purposes:  it checks that A's calls to B are
    as expected, and it simulates B's behavior in response.  Given a system
    test for A and B, and a record of A's and B's behavior when the system test
    is run, we would like to automatically generate unit tests for A in which B
    is mocked.  The factored tests can isolate bugs in A from bugs in B and, if
    B is slow or expensive, improve test performance or cost.
    \par
    This paper motivates test factoring with an illustrative example, proposes
    a simple procedure for automatically generating mock objects for factored
    tests, and gives examples of how the procedure can be extended to larger
    change languages.",
  category = "Testing",
  csetags = "mernst,mernst-Testing,plse",
  basefilename = "mock-factoring-paste2004",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/mock-factoring-paste2004.pdf PDF;
    https://homes.cs.washington.edu/~mernst/pubs/mock-factoring-paste2004-slides.pdf slides (PDF);
    https://homes.cs.washington.edu/~mernst/pubs/mock-factoring-paste2004-slides.ppt slides (PowerPoint)",
  summary =
   "A set of small, fast-running tests can be more useful than a single
    larger test.  This paper proposes a way to automatically factor a large
    test case into smaller tests, using mock objects to model the environment.",
}


@InProceedings{McCamantE2004,
  author = 	 "Stephen McCamant and Michael D. Ernst",
  title = 	 "Early identification of incompatibilities in
                  multi-component upgrades",
  crossref =     "ECOOP2004",
  pages = 	 "440--464",
  basefilename = "upgrades-ecoop2004",
  category = "Defect prediction",
  csetags = "mernst,mernst-Bug-prediction,plse",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/upgrades-ecoop2004.pdf PDF",
  summary =
   "This paper extends the technique of ``Predicting problems caused by
    component upgrades'' [ESEC/FSE 2003] to deal with multi-module upgrades
    and arbitrary calling patterns.  It also presents 4 other enhancements
    and a case study of upgrading the C standard library as used by 48 Unix
    programs.",
  abstract =
   "Previous work proposed a technique for predicting problems resulting
    from replacing one version of a software component by another.  The
    technique reports, before performing the replacement or integrating the
    new component into a system, whether the upgrade could be problematic
    for that particular system.  This paper extends the technique to make
    it more applicable to real-world upgrades.  First, we extend the
    theoretical framework to handle more complex upgrades, including
    procedures that share state, callbacks, and simultaneous upgrades of
    multiple components.  The old model is a special case of our new one.
    Second, we show how to handle four real-world situations that were not
    addressed by previous work: non-local state, non-determinism,
    distinguishing old from new incompatibilities, and lack of test suites.
    Third, we present a case study in which we upgrade the Linux C library,
    for 48 Unix programs.  Our implementation identified real
    incompatibilities among versions of the C library that affected some of
    the programs, and it approved the upgrades for other programs that were
    unaffected by the changes.",
  usesDaikon = 1,
}


@Article{NeWinEGKL04:STTT,
  author = 	 "Toh {Ne Win} and Michael D. Ernst and Stephen J. Garland and Dilsun K{\i}rl{\i} and Nancy Lynch",
  authorASCII =  "Toh Ne Win and Michael D. Ernst and Stephen J. Garland and Dilsun Kirli and Nancy Lynch",
  title = 	 "Using simulated execution in verifying distributed algorithms",
  journal = 	 STTT,
  year = 	 2004,
  volume =	 6,
  number =	 1,
  pages =	 "67--76",
  month =	 jul,
  abstract =
   "This paper presents a methodology for using simulated execution to
    assist a theorem prover in verifying safety properties of distributed
    systems.  Execution-based techniques such as testing can increase
    confidence in an implementation, provide intuition about behavior, and
    detect simple errors quickly.  They cannot by themselves demonstrate
    correctness.  However, they can aid theorem provers by suggesting
    necessary lemmas and providing tactics to structure proofs.  This
    paper describes the use of these techniques in a machine-checked proof
    of correctness of the Paxos algorithm for distributed consensus.",
  basefilename = "simexecution-sttt2004",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/simexecution-sttt2004.pdf PDF",
  downloads =
   "https://homes.cs.washington.edu/~mernst/pubs/simexecution-vmcai2003-slides.pdf slides (PDF);
    https://homes.cs.washington.edu/~mernst/pubs/simexecution-vmcai2003-slides.ppt slides (PowerPoint)",
  category = "Distributed systems,Verification",
  csetags = "mernst,mernst-Verification,plse",
  summary =
   "This paper proposes integration of dynamic analysis with traditional
    theorem-proving in ways that extend beyond mere testing.  Generalizing
    over the test runs can reveal necessary lemmas, and the structure of
    the proof can mirror the structure of the execution.",
  usesDaikon = 1,
  undergradCoauthor = 1,
}



@InProceedings{SaffE2004:ISSTA,
  author =	 "David Saff and Michael D. Ernst",
  title =	 "An experimental evaluation of continuous testing during
                  development",
  crossref =     "ISSTA2004",
  pages = 	 "76--85",
  abstract =
   "Continuous testing uses excess cycles on a developer's workstation to
    continuously run regression tests in the background, providing rapid
    feedback about test failures as source code is edited.  It is intended to
    reduce the time and energy required to keep code well-tested and prevent
    regression errors from persisting uncaught for long periods of time.  This
    paper reports on a controlled human experiment to evaluate whether students
    using continuous testing are more successful in completing programming
    assignments.  We also summarize users' subjective impressions and discuss
    why the results may generalize.
    \par
    The experiment indicates that the tool has a statistically significant
    effect on success in completing a programming task, but no such effect on
    time worked.  Participants using continuous testing were three times as
    likely to complete the task before the deadline.
    Participants using continuous compilation were twice as likely to complete
    the task, providing empirical support to a common feature in modern
    development environments.  Most participants found continuous testing to be
    useful and believed that it helped them write better code faster, and 90\%
    would recommend the tool to others.  The participants did not find the tool
    distracting, and intuitively developed ways of incorporating the feedback
    into their workflow.",
  category = "Testing",
  csetags = "mernst,mernst-Testing,plse",
  basefilename = "ct-user-study-issta2004",
  downloads =    "https://groups.csail.mit.edu/pag/continuoustesting/ Eclipse plug-in",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/ct-user-study-issta2004.pdf PDF",
  LOSTdownloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/ct-user-study.ppt PowerPoint",
  summary =
   "Continuous testing during development provides early notification of
    errors.  This paper reports a controlled experiment to measure whether
    and how programmers benefit from continuous testing.",
}


@InProceedings{LinE2004,
  author =	 "Lee Lin and Michael D. Ernst",
  title =	 "Improving adaptability via program steering",
  crossref =     "ISSTA2004",
  pages = 	 "206--216",
  abstract =
   "A multi-mode software system contains several distinct modes of operation
    and a controller for deciding when to switch between modes.  Even when
    developers rigorously test a multi-mode system before deployment, they
    cannot foresee and test for every possible usage scenario.  As a result,
    unexpected situations in which the program fails or underperforms (for
    example, by choosing a non-optimal mode) may arise.  This research aims to
    mitigate such problems by creating a new mode selector that examines the
    current situation, then chooses a mode that has been successful in the
    past, in situations like the current one.  The technique, called program
    steering, creates a new mode selector via machine learning from good
    behavior in testing or in successful operation.  Such a strategy, which
    generalizes the knowledge that a programmer has built into the system, may
    select an appropriate mode even when the original controller cannot.  We
    have performed experiments on robot control programs written in a
    month-long programming competition.  Augmenting these programs via our
    program steering technique had a substantial positive effect on their
    performance in new environments.",
  basefilename = "steering-issta2004",
  downloadsnonlocal =
      "https://homes.cs.washington.edu/~mernst/pubs/steering-issta2004.pdf PDF;
       https://homes.cs.washington.edu/~mernst/pubs/steering-issta2004.ppt slides (PowerPoint)",
  category = "Program repair",
  csetags = "mernst,mernst-Dynamic-analysis,plse",
  summary =
   "Program steering selects modalities for a program that may operate in
    several modes.  This paper's experiments show that program steering can
    substantially improve performance in unanticipated situations.",
  usesDaikon = 1,
  undergradCoauthor = 1,
}


@TechReport{PachecoE2004,
  author =	 "Carlos Pacheco and Michael D. Ernst",
  title =	 "Eclat: Automatic generation and classification of test inputs",
  institution =  MITLCS,
  year = 	 2004,
  number =	 968,
  address =	 MITaddr,
  month =	 oct,
  abstract =
   "This paper describes a technique that helps a test engineer select, from a
    large set of randomly generated test inputs, a small subset likely to
    reveal faults in the software under test.  The technique takes a program or
    software component, plus a set of normal executions{\,---\,}say, from an
    existing test suite, or from observations of the software running properly.
    The technique works by extracting an operational model of the software's
    operation, and comparing each input's operational pattern of execution
    against the model. Test inputs whose operational pattern is suggestive of a
    fault are further reduced by selecting only one input per such pattern. The
    result is a small portion of the original inputs, deemed most likely to
    reveal faults.  Thus, our technique can also be seen as an error-detection
    technique.
    \par
    We have implemented these ideas in the Eclat tool, designed for unit
    testing of Java classes. Eclat generates a large number of inputs and uses
    our technique to select only a few of them as fault-revealing.  The inputs
    that it selects are an order of magnitude more likely to reveal faults than
    non-selected inputs.",
  basefilename = "classify-tests-tr968",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/classify-tests-tr968.pdf PDF",
  category = "Test generation",
  csetags = "mernst,mernst-Testing,plse",
  summary =
   "This paper presents an automatic mechanism for selecting tests that are
    likely to expose errors in a software system.  The technique selects tests
    whose run-time behavior is maximally different from succeeding runs.",
  supersededby = "PachecoE2005",
  usesDaikon =   1,
}


@InProceedings{BirkaE2004,
  author = 	 "Adrian Birka and Michael D. Ernst",
  title = 	 "A practical type system and language for reference immutability",
  crossref =     "OOPSLA2004",
  pages = 	 "35--49",
  basefilename = "ref-immutability-oopsla2004",
  downloads =
    "https://types.cs.washington.edu/javari/ Javari implementation",
  downloadsnonlocal =
    "https://homes.cs.washington.edu/~mernst/pubs/ref-immutability-oopsla2004.pdf PDF;
     https://homes.cs.washington.edu/~mernst/pubs/ref-immutability-oopsla2004-slides.pdf slides (PDF)",
  category = "Immutability (side effects)",
  csetags = "mernst,mernst-Immutability-(side-effects),plse",
  summary =
   "This paper presents a type system, language, implementation, and
    evaluation of a safe mechanism for enforcing reference immutability,
    where an immutable reference may not be used to cause side effects to any
    object reachable from it.",
  abstract =
   "This paper describes a type system that is capable of expressing and
    enforcing immutability constraints.  The specific constraint expressed is
    that the abstract state of the object to which an immutable reference
    refers cannot be modified using that reference.  The abstract state is
    (part of) the transitively reachable state: that is, the state of the
    object and all state reachable from it by following references.  The type
    system permits explicitly excluding fields or objects from the abstract
    state of an object.  For a statically type-safe language, the type system
    guarantees reference immutability.  If the language is extended with
    immutability downcasts, then run-time checks enforce the reference
    immutability constraints.
    \par
    In order to better understand the usability and efficacy of the type
    system, we have implemented an extension to Java, called Javari, that
    includes all the features of our type system.  Javari is interoperable
    with Java and existing JVMs.  It can be viewed as a proposal for the
    semantics of the Java \texttt{const} keyword, though Javari's syntax uses
    \texttt{readonly} instead.  This paper describes the design and
    implementation of Javari, including the type-checking rules for the
    language.  This paper also discusses experience with 160,000 lines of
    Javari code.  Javari was easy to use and provided a number of benefits,
    including detecting errors in well-tested code.",
  usesDaikonAsTestSubject = 1,
  undergradCoauthor = 1,
}


@InProceedings{DonovanKTE2004,
  author =	 "Alan Donovan and Adam Kie{\.z}un and Matthew S. Tschantz and Michael D. Ernst",
  authorASCII =  "Adam Kiezun",
  title =	 "Converting {Java} programs to use generic libraries",
  crossref =     "OOPSLA2004",
  pages = 	 "15--34",
  abstract =
   "Java 1.5 will include a type system (called JSR-14) that supports
    \emph{parametric polymorphism}, or \emph{generic} classes.  This will bring
    many benefits to Java programmers, not least because current Java practice
    makes heavy use of logically-generic classes, including container classes.
    \par
    Translation of Java source code into semantically equivalent JSR-14 source
    code requires two steps: parameterization (adding type parameters to class
    definitions) and instantiation (adding the type arguments at each use of a
    parameterized class).  Parameterization need be done only once for a class,
    whereas instantiation must be performed for each client, of which there are
    potentially many more.  Therefore, this work focuses on the instantiation
    problem.  We present a technique to determine sound and precise JSR-14
    types at each use of a class for which a generic type specification is
    available.  Our approach uses a precise and context-sensitive pointer
    analysis to determine possible types at allocation sites, and a
    set-constraint-based analysis (that incorporates guarded, or conditional,
    constraints) to choose consistent types for both allocation and declaration
    sites.  The technique handles all features of the JSR-14 type system,
    notably the raw types that provide backward compatibility.  We have
    implemented our analysis in a tool that automatically inserts type
    parameters into Java code, and we report its performance when applied to a
    number of real-world Java programs.",
  basefilename = "instantiating-generics-oopsla2004",
  downloadsnonlocal =
    "https://homes.cs.washington.edu/~mernst/pubs/instantiating-generics-oopsla2004.pdf PDF;
     https://homes.cs.washington.edu/~mernst/pubs/instantiating-generics-oopsla2004-slides.pdf slides (PDF)",
  category = "Refactoring",
  csetags = "mernst,mernst-Refactoring,plse",
  summary =
   "When type parameters are added to library code, client code should be
    upgraded to supply parameters at each use of library classes.  This
    paper presents a sound and precise combined pointer and type-based
    analysis that does so.",
  undergradCoauthor = 1,
}


@InProceedings{McCamantE2004:formalizing-upgrades,
  author = 	 "Stephen McCamant and Michael D. Ernst",
  title = 	 "Formalizing lightweight verification of software component composition",
  crossref =     "SAVCBS2004",
  pages = 	 "47--54",
  abstract =
   "Software errors often occur at the interfaces between separately developed
    components.  Incompatibilities are an especially acute problem when
    upgrading software components, as new versions may be accidentally
    incompatible with old ones.  As an inexpensive mechanism to detect many
    such problems, previous work proposed a technique that adapts methods from
    formal verification to use component abstractions that can be automatically
    generated from implementations.  The technique reports, before performing
    the replacement or integrating the new component into a system, whether the
    upgrade might be problematic for that particular system.  The technique is
    based on a rich model of components that support internal state, callbacks,
    and simultaneous upgrades of multiple components, and component
    abstractions may contain arbitrary logical properties including
    unbounded-state ones.
    \par
    This paper motivates this (somewhat non-standard) approach to component
    verification.  The paper also refines the formal model of components,
    provides a formal model of software system safety, gives an algorithm for
    constructing a consistency condition, proves that the algorithm's result
    guarantees system safety in the case of a single-component upgrade, and
    gives a proof outline of the algorithm's correctness in the case of an
    arbitrary upgrade.",
  basefilename = "upgrades-savcbs2004",
  downloadsnonlocal =
    "https://homes.cs.washington.edu/~mernst/pubs/upgrades-savcbs2004.pdf PDF",
  category = "Defect prediction",
  csetags = "mernst,mernst-Bug-prediction,plse",
  summary =
   "This paper formalizes (and corrects a few mistakes in) previous work on
    predicting problems caused by component upgrades.  It presents an outline
    for a proof that the technique permits only sound upgrades.",
  usesDaikon = 1,
}


@InProceedings{PerkinsE2004,
  author =	 "Jeff H. Perkins and Michael D. Ernst",
  title =	 "Efficient incremental algorithms for dynamic detection of
                  likely invariants",
  crossref =     "FSE2004",
  pages = 	 "23--32",
  basefilename = "invariants-incremental-fse2004",
  downloads = "https://plse.cs.washington.edu/daikon/ Daikon implementation",
  downloadsnonlocal =
    "https://homes.cs.washington.edu/~mernst/pubs/invariants-incremental-fse2004.pdf PDF;
     https://homes.cs.washington.edu/~mernst/pubs/invariants-incremental-fse2004-slides.pdf slides (PDF)",
  category = "Specification inference",
  csetags = "mernst,mernst-Invariant-detection,plse",
  summary =
   "This paper shows how to perform dynamic invariant detection both
    incrementally, efficiently, and without using only a trivial grammar;
    previous implementations suffered from one or more such problems.",
  abstract =
   "Dynamic detection of likely invariants is a program analysis that
    generalizes over observed values to hypothesize program properties.  The
    reported program properties are a set of likely invariants over the
    program, also known as an operational abstraction.  Operational
    abstractions are useful in testing, verification, bug detection,
    refactoring, comparing behavior, and many other tasks.
    \par
    Previous techniques for dynamic invariant detection scale poorly or
    report too few properties.  Incremental algorithms are attractive because
    they process each observed value only once and thus scale well with data
    sizes.  Previous incremental algorithms only checked and reported a small
    number of properties.  This paper takes steps toward correcting this
    problem.  The paper presents two new incremental algorithms for invariant
    detection and compares them analytically and experimentally to two
    existing algorithms.  Furthermore, the paper presents four optimizations
    and shows how to implement them in the context of incremental algorithms.
    The result is more scalable invariant detection that does not sacrifice
    functionality.",
  usesDaikonAsTestSubject = 1,
}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%% 2005
%%%

@InProceedings{ErnstC2005,
  author = 	 "Michael D. Ernst and John Chapin",
  title = 	 "The {Groupthink} specification exercise",
  crossref =     "ICSE2005",
  pages = 	 "617--618",
  abstract =
   "Teaching students to read and write specifications is difficult.  It is
    even more difficult to motivate specifications{\,---\,}to convince
    students of the value of specifications and make students eager to use
    them.  This paper describes the Groupthink specification exercise.
    Groupthink is a fun group activity, in the style of a game show, that
    teaches students about specifications (the difficulty of writing them,
    techniques for getting them right, and criteria for evaluating them),
    teamwork, and communication.  Specifications are not used as an end in
    themselves, but are motivated to students as a means to solving realistic
    problems that involve understanding system behavior.  Students enjoy the
    activity, and it improves their ability to read and write specifications.
    The two-hour, low-prep activity is self-contained, scales from
    classes of ten to hundreds of students, and is freely available to other
    instructors.",
  basefilename = "groupthink-icse2005",
  downloadsnonlocal =
    "https://homes.cs.washington.edu/~mernst/pubs/groupthink-icse2005.pdf PDF",
  category = "Education",
  csetags = "mernst,mernst-Software-engineering,plse",
  summary =
   "The Groupthink specification exercise is a fun group activity that
    teaches students about specifications (the difficulty of writing them,
    techniques for getting them right, and criteria for evaluating them),
    teamwork, and communication.",
  supersededby = "Ernst2006",
}


@InProceedings{SaffE2005:CT-demo,
  author = 	 "David Saff and Michael D. Ernst",
  title = 	 "Continuous testing in {Eclipse}",
  crossref =     "ICSE2005",
  pages = 	 "668--669",
  abstract =
   "Continuous testing uses excess cycles on a developer's workstation to
    continuously run regression tests in the background, providing rapid
    feedback about test failures as code is edited. It reduces the time and
    energy required to keep code well-tested, and it prevents regression errors
    from persisting uncaught for long periods of time.",
  supersededby = "SaffE2004:ETX A tool demonstration",
  basefilename = "conttest-demo-icse2005",
  downloads =    "https://groups.csail.mit.edu/pag/continuoustesting/ Eclipse plug-in",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/conttest-demo-icse2005.pdf PDF",
  category = "Testing",
  OMITcsetagsBECAUSESUPERSEDED = "mernst,mernst-Testing,plse",
  summary =
   "The Eclipse plug-in for continuous testing automatically runs tests to
    keep developers informed of the state of their code, integrates with
    Eclipse's build and notification system, and supports test
    prioritization, test selection, hotswapping, and remote execution.",
}


@TechReport{SaffAPE2005:TR,
  author =	 "David Saff and Shay Artzi and Jeff H. Perkins and Michael D. Ernst",
  title =	 "Automatic test factoring for {Java}",
  institution =  MITLCS,
  year = 	 2005,
  number = 	 "MIT-LCS-TR-991",
  address =	 MITaddr,
  month =	 jun # "~7,",
  supersededby = "SaffAPE2005",
  basefilename = "test-factoring-tr991",
  category = "Testing",
  OMITcsetagsBECAUSESUPERSEDED = "mernst,mernst-Testing,plse",
  summary =
   "Test factoring creates fast, focused unit tests from slow system-wide
    tests.  Each new unit test exercises only a subset of the functionality
    exercised by the system test.",
  abstract =
   "\emph{Test factoring} creates fast, focused unit tests from slow system-wide
    tests; each new unit test exercises only a subset of the functionality
    exercised by the system test.  Augmenting a test suite with factored unit
    tests should catch errors earlier in a test run.
    \par
    One way to factor a test is to introduce \emph{mock objects}.  If a test
    exercises a component T, which interacts with another component E (the
    ``environment''), the implementation of E can be replaced by a {\em mock}.
    The mock checks that T's calls to E are as expected, and it simulates
    E's behavior in response.  We introduce an automatic technique for test
    factoring.  Given a system test for T and E, and a record of T's and
    E's behavior when the system test is run, test factoring generates unit
    tests for T in which E is mocked.  The factored tests can isolate bugs in
    T from bugs in E and, if E is slow or expensive, improve test
    performance or cost.
    \par
    We have built an implementation of automatic dynamic test factoring for the
    Java language.  Our experimental data indicates that it can reduce the
    running time of a system test suite by up to an order of magnitude.",
}


@Article{BurdyCCEKLLP2005,
  author = 	 "Lilian Burdy and Yoonsik Cheon and David Cok and
		   Michael D. Ernst and Joe Kiniry and Gary T. Leavens and
		   K. Rustan M. Leino and Erik Poll",
  title = 	 "An overview of {JML} tools and applications",
  journal = 	 STTT,
  year = 	 2005,
  volume =	 7,
  number =	 3,
  pages =	 "212--232",
  month =	 jun,
  basefilename = "jml-tools-sttt2005",
  downloadsnonlocal =
    "https://homes.cs.washington.edu/~mernst/pubs/jml-tools-sttt2005.pdf PDF",
  category = "Verification",
  csetags = "mernst,mernst-Verification,plse",
  summary =
   "This paper overviews the Java Modeling Language (JML) notation for
    detailed design and gives a brief description of some of the tools that
    take it as an input or produce it as an output.",
  abstract =
   "The Java Modeling Language (JML) can be used to specify the detailed design
    of Java classes and interfaces by adding annotations to Java source
    files. The aim of JML is to provide a specification language that is easy
    to use for Java programmers and that is supported by a wide range of tools
    for specification type-checking, runtime debugging, static analysis, and
    verification.
    \par
    This paper gives an overview of the main ideas behind JML, details
    about JML's wide range of tools, and a glimpse into existing
    applications of JML.",
  usesDaikon = 1,
}


@InProceedings{PachecoE2005,
  author =	 "Carlos Pacheco and Michael D. Ernst",
  title =	 "Eclat: Automatic generation and classification of test inputs",
  crossref =     "ECOOP2005",
  pages = 	 "504--527",
  abstract =
   "This paper describes a technique that selects, from a large set of test
    inputs, a small subset likely to reveal faults in the software under test.
    The technique takes a program or software component, plus a set of correct
    executions---say, from observations of the software running properly, or
    from an existing test suite that a user wishes to enhance.  The technique
    first infers an operational model of the software's operation.  Then,
    inputs whose operational pattern of execution differs from the model in
    specific ways are suggestive of faults.  These inputs are further reduced
    by selecting only one input per operational pattern. The result is a small
    portion of the original inputs, deemed by the technique as most likely to
    reveal faults.  Thus, the technique can also be seen as an error-detection
    technique.
    \par
    The paper describes two additional techniques that complement test input
    selection.  One is a technique for automatically producing an oracle (a set
    of assertions) for a test input from the operational model, thus
    transforming the test input into a test case.  The other is a
    classification-guided test input generation technique that also makes use
    of operational models and patterns.  When generating inputs, it filters out
    code sequences that are unlikely to contribute to legal inputs, improving
    the efficiency of its search for fault-revealing inputs.
    \par
    We have implemented these techniques in the Eclat tool, which generates
    unit tests for Java classes. Eclat's input is a set of classes to test and
    an example program execution---say, a passing test suite. Eclat's output is
    a set of JUnit test cases, each containing a potentially fault-revealing
    input and a set of assertions at least one of which fails.  In our
    experiments, Eclat successfully generated inputs that exposed
    fault-revealing behavior; we have used Eclat to reveal real errors in
    programs.  The inputs it selects as fault-revealing are an order of
    magnitude as likely to reveal a fault as all generated inputs.",
  basefilename = "classify-tests-ecoop2005",
  downloads =
   "https://groups.csail.mit.edu/pag/eclat/ Eclat implementation;
    https://randoop.github.io/randoop/ Randoop implementation",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/classify-tests-ecoop2005.pdf PDF",
  category = "Test generation",
  csetags = "mernst,mernst-Testing,plse",
  summary =
   "This paper presents an automatic mechanism for selecting tests that are
    likely to expose errors---tests whose run-time behavior is maximally
    different from succeeding runs.  The paper also gives techniques for
    test input generation and for converting a test input into a test case.",
  usesDaikon = 1,
}


@InProceedings{WilliamsTE2005,
  author = 	 "Amy Williams and William Thies and Michael D. Ernst",
  title = 	 "Static deadlock detection for {Java} libraries",
  crossref =     "ECOOP2005",
  pages = 	 "602--629",
  abstract =
   "Library writers wish to provide a guarantee not only that each
    procedure in the library performs correctly in isolation, but also
    that the procedures perform correctly when run in conjunction.  To
    this end, we propose a method for static detection of deadlock in Java
    libraries.  Our goal is to determine whether client code exists that
    may deadlock a library, and, if so, to enable the library writer to
    discover the calling patterns that can lead to deadlock.
    \par
    Our flow-sensitive, context-sensitive analysis determines possible
    deadlock configurations using a lock-order graph.  This graph
    represents the order in which locks are acquired by the library.
    Cycles in the graph indicate deadlock possibilities, and our tool
    reports all such possibilities.  We implemented our analysis and
    evaluated it on 18 libraries comprising 1245 kLOC\@.
    We verified 13 libraries to be free from deadlock,
    and found 14 distinct deadlocks in 3 libraries.",
  basefilename = "deadlock-library-ecoop2005",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/deadlock-library-ecoop2005.pdf PDF",
  category = "Concurrency",
  csetags = "mernst,mernst-Static-analysis,plse,plse-lockcaps",
  summary =
   "This paper gives a technique for determining whether any invocation of
    a library can lead to deadlock in the client program; it can also be
    extended to the closed-world (whole-program) case.",
}



@InProceedings{Ernst2005:VSTTE,
  author = 	 "Michael D. Ernst",
  title = 	 "Verification for legacy programs",
  crossref =	 "VSTTE2005",
  abstract =
   "In the long run, programs should be written from the start with
    verification in mind.  Programs written in such a way are likely to be much
    easier to verify.  They will avoid hard-to-verify features, may have better
    designs, will be accompanied by full formal specifications, and may be
    annotated with verification information.  However, even if programs
    \emph{should} be written this way, not all of them will.  In the short run,
    it is crucial to verify the legacy programs that make up our existing
    computing infrastructure, and to provide tools that assist programmers in
    performing verification tasks and --- equally importantly --- in shifting
    their mindset to one of program verification.  I propose approaches to
    verification that may assist in reaching these goals.
    \par
    The key idea underlying the approaches is specification inference.  This is
    a machine learning technique that produces, from an existing program, a
    (likely) specification of that program.  Specifications are very frequently
    missing from real-world programs, but are required for verification.  The
    inferred specification can serve as a goal for verification.  I discuss
    three different approaches that can use such inferred specifications.  One
    uses a heavyweight proof assistant, one uses an automated theorem prover,
    and one requires no user interaction but provides no guarantee.",
  basefilename = "legacy-verification-vstte2005",
  downloadsnonlocal =
    "https://homes.cs.washington.edu/~mernst/pubs/legacy-verification-vstte2005.pdf PDF;
     https://homes.cs.washington.edu/~mernst/pubs/legacy-verification-vstte2005-slides.pdf slides (PDF)",
  category = "Verification",
  csetags = "mernst,mernst-Verification,plse",
  summary =
   "Legacy (under-documented and -specified) code will be with us forever.  This
    paper suggests ways to cope with such systems, both to ameliorate short-term
    problems and to advance toward a future in which all code is verified."
}



@InProceedings{TschantzE2005,
  author =	 "Matthew S. Tschantz and Michael D. Ernst",
  title =	 "Javari: Adding reference immutability to {Java}",
  crossref =     "OOPSLA2005",
  pages = 	 "211--230",
  basefilename = "ref-immutability-oopsla2005",
  alsosee = "Tschantz2006",
  downloads =
   "https://groups.csail.mit.edu/pag/pubs/tschantz-refimmut-mengthesis.pdf extended version (PDF);
    https://types.cs.washington.edu/javari/ Javari implementation",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/ref-immutability-oopsla2005.pdf PDF;
    https://homes.cs.washington.edu/~mernst/pubs/ref-immutability-oopsla2005-slides.ppt slides (PowerPoint)",
  category = "Immutability (side effects)",
  csetags = "mernst,mernst-Immutability-(side-effects),plse",
  summary =
   "A compiler can guarantee that an immutable reference is not used to cause
    side effects to any reachable object. This paper extends previous proposals
    in many ways, including formal type rules and support for Java generics.",
  abstract =
   "This paper describes a type system that is capable of expressing and
    enforcing immutability constraints.  The specific constraint expressed is
    that the abstract state of the object to which an immutable reference
    refers cannot be modified using that reference.  The abstract state is
    (part of) the transitively reachable state: that is, the state of the
    object and all state reachable from it by following references.  The type
    system permits explicitly excluding fields from the abstract
    state of an object.  For a statically type-safe language, the type system
    guarantees reference immutability.  If the language is extended with
    immutability downcasts, then run-time checks enforce the reference
    immutability constraints.
    \par
    This research builds upon previous research in language support for
    reference immutability.  Improvements that are new in this paper include
    distinguishing the notions of assignability and mutability; integration
    with Java 5's generic types and with multi-dimensional arrays; a mutability
    polymorphism approach to avoiding code duplication; type-safe support for
    reflection and serialization; and formal type rules and type soundness proof
    for a core calculus.  Furthermore, it retains the valuable
    features of the previous dialect, including usability by humans (as
    evidenced by experience with 160,000 lines of Javari code) and
    interoperability with Java and existing JVMs.",
  undergradCoauthor = 1,
}


@InProceedings{ArtziE2005,
  author =	 "Shay Artzi and Michael D. Ernst",
  title =	 "Using predicate fields in a highly flexible industrial
                  control system",
  crossref =     "OOPSLA2005",
  pages = 	 "319--330",
  basefilename = "predicate-fields-oopsla2005",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/predicate-fields-oopsla2005.pdf PDF",
  category = "Programming language design",
  csetags = "mernst,mernst-Programming-language-design,plse",
  summary =
   "Predicate-oriented programming has not previously been evaluated outside
    a research context.  This paper describes a case study that evaluates the
    use of predicate fields in a large-scale application that is in daily use.",
  abstract =
   "Predicate fields allow an object's structure to vary at runtime based on
    the object's state:  a predicate field is present or not, depending on the
    values of other fields.  Predicate fields and related concepts have not
    previously been evaluated outside a research environment. We present a case
    study of two industrial applications with similar requirements, one of
    which uses predicate fields and one of which does not. The use of predicate
    fields was motivated by requirements for high flexibility, by
    unavailability of many requirements, and by high user interface development
    costs.  Despite an implementation of predicate fields as a library (rather
    than as a language extension), developers found them natural to use, and in
    many cases they significantly reduced development effort.",
}


@Proceedings{PASTE2005:proc,
  title = 	 "PASTE: ACM SIGPLAN/SIGSOFT Workshop on Program Analysis for
		  Software Tools and Engineering",
  year = 	 2005,
  editor =	 "Michael D. Ernst and Thomas Jensen",
  address =	 "Lisbon, Portugal",
  month =	 sep,
  basefilename = "paste2005-proceedings",
  downloads =    "https://homes.cs.washington.edu/~mernst/meetings/paste2005/ workshop website",
  category = "Software engineering",
  csetags = "mernst,mernst-Software-engineering,plse",
  summary =
   "PASTE 2005 brought together the program analysis, software tools, and
    software engineering communities to focus on applications of program
    analysis techniques in software tools.",
  abstract =
   "PASTE 2005 is the fifth workshop in a series that brings together the
    program analysis, software tools, and software engineering communities to
    focus on applications of program analysis techniques in software
    tools. PASTE 2005 provides a forum for the presentation of exciting
    research, empirical results, and new directions in areas including (but not
    limited to):
    \begin{itemize}
    \item program analysis for program understanding, debugging, testing, and
    reverse engineering
    \item integration of program analysis into programming environments
    \item user interfaces for software tools and software visualization
    \item applications of program slicing, model checking, and other program
    analysis techniques
    \item analysis of program execution or program evolution
    \item integration of, or tradeoffs between, different analysis techniques
    \item issues in scaling analyses and user interfaces to deal with large
    systems
    \end{itemize}"
}


@InProceedings{SaffAPE2005,
  author =	 "David Saff and Shay Artzi and Jeff H. Perkins and Michael D. Ernst",
  title =	 "Automatic test factoring for {Java}",
  crossref =     "ASE2005",
  pages = 	 "114--123",
  basefilename = "test-factoring-ase2005",
  downloadsnonlocal =
    "https://homes.cs.washington.edu/~mernst/pubs/test-factoring-ase2005.pdf PDF",
  category = "Testing",
  csetags = "mernst,mernst-Testing,plse",
  summary =
   "Test factoring creates fast, focused unit tests from slow system-wide
    tests.  Each new unit test exercises only a subset of the functionality
    exercised by the system test.",
  abstract =
   "\emph{Test factoring} creates fast, focused unit tests from slow system-wide
    tests; each new unit test exercises only a subset of the functionality
    exercised by the system test.  Augmenting a test suite with factored unit
    tests should catch errors earlier in a test run.
    \par
    One way to factor a test is to introduce \emph{mock objects}.  If a test
    exercises a component T, which interacts with another component E (the
    ``environment''), the implementation of E can be replaced by a {\em mock}.
    The mock checks that T's calls to E are as expected, and it simulates
    E's behavior in response.  We introduce an automatic technique for test
    factoring.  Given a system test for T and E, and a record of T's and
    E's behavior when the system test is run, test factoring generates unit
    tests for T in which E is mocked.  The factored tests can isolate bugs in
    T from bugs in E and, if E is slow or expensive, improve test
    performance or cost.
    \par
    Our implementation of automatic dynamic test factoring for the Java
    language reduces the running time of a system test suite by up to an
    order of magnitude.",
  usesDaikonAsTestSubject = 1,
}


@Misc{ErnstP2005,
  author =	 "Michael D. Ernst and Jeff H. Perkins",
  title =	 "Learning from executions:  Dynamic analysis for software
                  engineering and program understanding",
  note =         "Tutorial at ASE 2005",
  OMIThowpublished = "Tutorial at ASE 2005",
  month =	 nov,
  year =	 2005,
  basefilename = "dynamic-tutorial-ase2005",
  downloadsnonlocal =
    "dynamic-tutorial-ase2005-main.pdf slides 1 (PDF);
     dynamic-tutorial-ase2005-java-instrumentation.pdf.pdf slides 2 (PDF);
     dynamic-tutorial-ase2005-compiled-instrumentation.pdf slides 3 (PDF);
     dynamic-tutorial-ase2005-data-analysis.pdf slides 4 (PDF)",
  downloadsnonlocal =
    "https://homes.cs.washington.edu/~mernst/pubs/dynamic-tutorial-ase2005-main.pdf slides 1 (PDF);
     https://homes.cs.washington.edu/~mernst/pubs/dynamic-tutorial-ase2005-java-instrumentation.pdf slides 2 (PDF);
     https://homes.cs.washington.edu/~mernst/pubs/dynamic-tutorial-ase2005-compiled-instrumentation.pdf slides 3 (PDF);
     https://homes.cs.washington.edu/~mernst/pubs/dynamic-tutorial-ase2005-data-analysis.pdf slides 4 (PDF)",
  category = "Dynamic analysis",
  csetags = "mernst,mernst-Dynamic-analysis,plse",
  summary =
   "A broad overview of the field of dynamic analysis, including
    applications of dynamic analysis, dynamic analysis algorithms, and
    implementation details.  The slides capture only part of the tutorial,
    and naturally the tutorial only captures part of this exciting field.",
  abstract =
   "The software engineering community increasingly recognizes the importance
    and value of dynamic analysis for program understanding.  A dynamic
    analysis runs a program and observes its execution.  Dynamic analysis for
    program understanding produces output, or feeds into a subsequent analysis,
    that enables programming tasks or increases human understanding of the
    code; this transcends traditional dynamic analysis for testing or
    optimization.
    \par
    Dynamic analysis complements traditional static analyses, such as compilers
    and type checkers, that have similar goals.  Once largely ignored by the
    research community due to unsoundness, of late there has been a flowering
    of research in this area.  Often, a dynamic analysis is more precise and
    can better handle incomplete programs, programs written in multiple
    languages, and analysis of program environments, among other situations.
    \par
    This tutorial will explore the active new area of program analysis for
    program understanding and software engineering.  It will cover theoretical
    background, implementation techniques, and applications, with particular
    focus on applications to practical programming tasks and on developing new
    applications.  It will also present tools that you can use or build on in
    your practice or research, with the opportunity for hands-on experience, if
    there is interest.
    \par
    The tutorial format will encourage questions, discussion, and interaction,
    in order to enable participants to get the most out of it."
}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%% 2006
%%%


@InProceedings{ErnstLP2006,
  author = 	 "Michael D. Ernst and Raimondas Lencevicius and Jeff H. Perkins",
  title = 	 "Detection of web service substitutability and composability",
  crossref =     "WSMATE2006",
  pages = 	 "123--135",
  abstract =
   "Web services are used in software applications as a standard and
    convenient way of accessing remote applications over the Internet.  Web
    services can be thought of as remote procedure calls.  This paper
    proposes an approach to determine web service substitutability and
    composability.  Because web services may be unreliable, finding other
    services substitutable for an existing one can increase application
    uptime.  Finding composable services enables applications to be
    programmed by composing several web services (using one service's output
    as an input to another web service).  We have implemented our technique
    and evaluated it on 14 freely available web services producing 92
    outputs.  Our approach correctly detects all composable and substitutable
    web services from this set.",
  basefilename = "web-service-subst-wsmate2006",
  downloadsnonlocal =
    "https://homes.cs.washington.edu/~mernst/pubs/web-service-subst-wsmate2006.pdf PDF",
  category = "Dynamic analysis",
  csetags = "mernst,mernst-Dynamic-analysis,plse",
  summary =
   "Programmers, end users, and even program would like to discover and
    reuse software services.  This paper presents an approach to indicate
    when Web Services may be substituted for one another or composed.",
}


@InProceedings{DemskyEGMPR2006,
  author =	 "Brian Demsky and Michael D. Ernst and Philip J. Guo and
		  Stephen McCamant and Jeff H. Perkins and Martin Rinard",
  title =	 "Inference and enforcement of data structure consistency specifications",
  crossref =     "ISSTA2006",
  pages = 	 "233--243",
  abstract =
   "Corrupt data structures are an important cause of unacceptable program
    execution. Data structure repair (which eliminates inconsistencies by
    updating corrupt data structures to conform to consistency
    constraints) promises to enable many programs to continue to execute
    acceptably in the face of otherwise fatal data structure corruption
    errors. A key issue is obtaining an accurate and comprehensive data
    structure consistency specification.
    \par
    We present a new technique for obtaining data structure consistency
    specifications for data structure repair. Instead of requiring the
    developer to manually generate such specifications, our approach
    automatically generates candidate data structure consistency
    properties using the Daikon invariant detection tool.  The developer
    then reviews these properties, potentially rejecting or generalizing
    overly specific properties to obtain a specification suitable for
    automatic enforcement via data structure repair.
    \par
    We have implemented this approach and applied it to three sizable
    benchmark programs: CTAS (an air-traffic control system), BIND (a
    widely-used Internet name server) and Freeciv (an interactive game).
    Our results indicate that (1) automatic constraint generation produces
    constraints that enable programs to execute successfully through data
    structure consistency errors, (2) compared to manual specification,
    automatic generation can produce more comprehensive sets of
    constraints that cover a larger range of data structure consistency
    properties, and (3) reviewing the properties is relatively
    straightforward and requires substantially less programmer effort than
    manual generation, primarily because it reduces the need to examine
    the program text to understand its operation and extract the relevant
    consistency constraints.  Moreover, when evaluated by a hostile third
    party ``Red Team'' contracted to evaluate the effectiveness of the
    technique, our data structure inference and enforcement tools
    successfully prevented several otherwise fatal attacks.",
  basefilename = "infer-repair-issta2006",
  downloadsnonlocal =
    "https://homes.cs.washington.edu/~mernst/pubs/infer-repair-issta2006.pdf PDF",
  category = "Program repair",
  csetags = "mernst,mernst-Dynamic-analysis,plse",
  summary =
   "This paper presents an automatic technique for recovering from data
    structure corruption errors.  It involves inferring correctness
    constraints, then repairing any errors that occur at run time.
    The evaluation includes a hostile ``Red Team'' evaluation.",
  usesDaikon =   1,
  undergradCoauthor = 1,
}


@TechReport{RinardE2006,
  author = 	 "Martin Rinard and Michael D. Ernst",
  title = 	 "Learning and repair techniques for self-healing systems",
  institution =  "Air Force Research Laboratory, Information Directorate",
  year = 	 2006,
  number = 	 "AFRL-IF-RS-TR-2006-157",
  address = 	 "Rome, NY, USA",
  month = 	 may,
  usesDaikon = 1,
  supersededby = "DemskyEGMPR2006",
  category = "Dynamic analysis",
}


@InProceedings{GuoPME2006,
  author = 	 "Philip J. Guo and Jeff H. Perkins and Stephen McCamant
                  and Michael D. Ernst",
  title = 	 "Dynamic inference of abstract types",
  crossref =     "ISSTA2006",
  pages = 	 "255--265",
  abstract =
   "An abstract type groups variables that are used for related purposes
    in a program.  We describe a dynamic unification-based analysis for
    inferring abstract types.  Initially, each run-time value gets a
    unique abstract type.  A run-time interaction among values indicates
    that they have the same abstract type, so their abstract types are
    unified.  Also at run time, abstract types for variables are
    accumulated from abstract types for values.  The notion of interaction
    may be customized, permitting the analysis to compute finer or coarser
    abstract types; these different notions of abstract type are useful
    for different tasks.  We have implemented the analysis for compiled
    x86 binaries and for Java bytecodes.  Our experiments indicate that
    the inferred abstract types are useful for program comprehension,
    improve both the results and the run time of a follow-on program
    analysis, and are more precise than the output of a comparable static
    analysis, without suffering from overfitting.",
  basefilename = "abstract-type-issta2006",
  downloads = "https://plse.cs.washington.edu/daikon/ DynComp implementation (distributed as part of Daikon)",
  downloadsnonlocal =
    "https://homes.cs.washington.edu/~mernst/pubs/abstract-type-issta2006.pdf PDF",
  category = "Dynamic analysis",
  csetags = "mernst,mernst-Dynamic-analysis,plse",
  summary =
   "This paper presents a dynamic analysis for computing abstract types,
    which indicate which values and variables may interact at run time.
    The paper also presents implementations and experiments for C++ and Java.",
  undergradCoauthor = 1,
}


@InProceedings{dAmorimPMXE2006,
  author = 	 "Marcelo d'Amorim and Carlos Pacheco and Darko Marinov and
                  Tao Xie and Michael D. Ernst",
  title = 	 "An empirical comparison of automated generation and
                  classification techniques for object-oriented unit testing",
  crossref =     "ASE2006",
  pages = 	 "59--68",
  abstract =
   "Testing involves two major activities: generating test inputs and
    determining whether they reveal faults.  Automated test generation
    techniques include random generation and symbolic execution.
    Automated test classification techniques include ones based on
    uncaught exceptions and violations of operational models inferred from
    manually provided tests.  Previous research on unit testing for
    object-oriented programs developed three pairs of these techniques:
    model-based random testing, exception-based random testing, and
    exception-based symbolic testing.  We develop a novel pair, model-based
    symbolic testing.  We also empirically compare all four pairs of these
    generation and classification techniques.  The results show that the
    pairs are complementary (i.e., reveal faults differently), with their
    respective strengths and weaknesses.",
  usesDaikon = 1,
  basefilename = "testgen-ase2006",
  downloadsnonlocal =
    "https://homes.cs.washington.edu/~mernst/pubs/testgen-ase2006.pdf PDF",
  category = "Test generation",
  csetags = "mernst,mernst-Testing,plse",
  summary =
   "This paper experimentally evaluates four test generation strategies:
    the four combinations of model-based vs.\ exception-based, and symbolic
    vs.\ random.  The model-based symbolic combination is new.",
}



@TechReport{ArtziEGKPP2006:TR,
  author = 	 "Shay Artzi and Michael D. Ernst and Adam Kie{\.z}un and Carlos Pacheco and Jeff H. Perkins",
  authorASCII =  "Adam Kiezun",
  title = 	 "Finding the needles in the haystack: Generating legal test inputs for object-oriented programs",
  institution =  MITCSAIL,
  year = 	 2006,
  number = 	 "MIT-CSAIL-TR-2006-056",
  address = 	 MITaddr,
  month = 	 sep # "~5,",
  abstract =
   "A test input for an object-oriented program typically consists of a
    sequence of method calls that use the API defined by the program
    under test. Generating legal test inputs can be challenging because,
    for some programs, the set of legal method sequences is much smaller
    than the set of all possible sequences; without a formal
    specification of legal sequences, an input generator is bound to
    produce mostly illegal sequences.
    \par
    We propose a scalable technique that combines dynamic analysis with
    random testing to help an input generator create legal test inputs
    without a formal specification, even for programs in which
    most sequences are illegal. The technique uses an example execution
    of the program to infer a model of legal call sequences, and uses
    the model to guide a random input generator towards legal but
    behaviorally-diverse sequences.
    \par
    We have implemented our technique for Java, in a tool called
    Palulu, and evaluated its effectiveness in creating legal inputs
    for real programs. Our experimental results indicate that the
    technique is effective and scalable. Our preliminary evaluation
    indicates that the technique can quickly generate legal sequences
    for complex inputs: in a case study, Palulu created legal test
    inputs in seconds for a set of complex classes, for which it took an
    expert thirty minutes to generate a single legal input.",
  supersededby = "ArtziEKPP2006",
  basefilename = "oo-test-gen-tr056",
  downloadsnonlocal =
    "https://homes.cs.washington.edu/~mernst/pubs/oo-test-gen-tr056.pdf PDF",
  category = "Test generation",
  OMITcsetagsBECAUSESUPERSEDED = "mernst,mernst-Testing,plse",
  summary =
   "An automatically inferred model of legal method call sequences can bias test
    generation toward legal method sequences, increasing coverage and creating
    data structures beyond the ability of undirected random generation.",
}


@TechReport{KiezunETF2006:TR,
  author = 	 "Adam Kie{\.z}un and Michael D. Ernst and Frank Tip and Robert M. Fuhrer",
  authorASCII =  "Adam Kiezun",
  title = 	 "Refactoring for parameterizing {Java} classes",
  institution =  MITCSAIL,
  year = 	 2006,
  number = 	 "MIT-CSAIL-TR-2006-061",
  address = 	 MITaddr,
  month = 	 sep # "~5,",
  abstract =
   "Type safety and expressiveness of many existing Java libraries and their
    client applications would improve, if the libraries were upgraded to define
    generic classes.  Efficient and accurate tools exist to assist client
    applications to use generics libraries, but so far the libraries themselves
    must be parameterized manually, which is a tedious, time-consuming, and
    error-prone task.  We present a type-constraint-based algorithm for
    converting non-generic libraries to add type parameters.  The algorithm
    handles the full Java language and preserves backward compatibility, thus
    making it safe for existing clients.  Among other features, it is capable
    of inferring wildcard types and introducing type parameters for
    mutually-dependent classes.  We have implemented the algorithm as a fully
    automatic refactoring in Eclipse.
    \par
    We evaluated our work in two ways.  First, our tool parameterized code that
    was lacking type parameters.  We contacted the developers of several of
    these applications, and in all cases where we received a response, they
    confirmed that the resulting parameterizations were correct and useful.
    Second, to better quantify its effectiveness, our tool parameterized
    classes from already-generic libraries, and we compared the results to
    those that were created by the libraries' authors.  Our tool performed the
    refactoring accurately---in 87\% of cases the results were as good as those
    created manually by a human expert, in 9\% of cases the tool results were
    better, and in 4\% of cases the tool results were worse.",
  supersededby = "KiezunETF2007",
  basefilename = "parameterizing-generics-tr",
  downloadsnonlocal =
    "https://homes.cs.washington.edu/~mernst/pubs/parameterizing-generics-tr.pdf PDF",
  category = "Refactoring",
  csetags = "mernst,mernst-Refactoring,plse",
  summary =
   "Programmers must change their programs to take advantage of generic types.
    This paper presents a type-constraint-based analysis that converts
    non-generic classes such as List into generic classes such as List<T>.",
}

@TechReport{PachecoLEB2006:TR,
  author = 	 "Carlos Pacheco and Shuvendu K. Lahiri and Michael D. Ernst and Thomas Ball",
  title = 	 "Feedback-directed random test generation",
  institution =  "Microsoft Research",
  year = 	 2006,
  number =	 "MSR-TR-2006-125",
  address = 	 MSRaddr,
  month =	 sep,
  OMITurl =          "https://research.microsoft.com/research/pubs/view.aspx?type=Technical%20Report&id=1171",
  abstract =
   "We present a technique that improves random test generation by
    incorporating feedback obtained from executing test inputs as they are
    created. Our technique builds inputs incrementally by randomly selecting a
    method call to apply and finding arguments from among
    previously-constructed inputs. As soon as an input is built, it is executed
    and checked against a set of contracts and filters. The result of the
    execution determines whether the input is redundant, illegal,
    contract-violating, or useful for generating more inputs. The technique
    outputs a test suite consisting of unit tests for the classes under
    test. Passing tests can be used to ensure that code contracts are preserved
    across program changes; failing tests (that violate one or more contract)
    point to potential errors that should be corrected. When applied to 14
    widely-used libraries comprising 780KLOC, feedback-directed random test
    generation finds many serious, previously-unknown errors. Compared with
    both systematic test generation and undirected random test generation,
    feedback-directed random test generation finds more errors, finds more
    severe errors, and produces fewer redundant tests.",
  supersededby = "PachecoLEB2007",
  basefilename = "feedback-testgen-tr125",
  downloadsnonlocal =
    "https://homes.cs.washington.edu/~mernst/pubs/feedback-testgen-tr125.pdf PDF",
  category = "Test generation",
  csetags = "mernst,mernst-Testing,plse",
  summary =
   "This paper presents a technique that improves random test generation by
    incorporating feedback from executing previously-generated inputs.  The
    technique found serious, previously-unknown errors in widely-deployed
    applications.",
}



@TechReport{ArtziEGK2006,
  author = 	 "Shay Artzi and Michael D. Ernst and David Glasser and Adam Kie{\.z}un",
  authorASCII =  "Adam Kiezun",
  title = 	 "Combined static and dynamic mutability analysis",
  institution =  MITCSAIL,
  year = 	 2006,
  number = 	 "MIT-CSAIL-TR-2006-065",
  address = 	 MITaddr,
  month = 	 sep # "~18,",
  abstract =
   "Knowing which method parameters may be mutated during a method's
    execution is useful for many software engineering tasks.  We present
    an approach to discovering parameter immutability, in which several
    lightweight, scalable analyses are combined in stages, with each stage
    refining the overall result.  The resulting analysis is scalable and
    combines the strengths of its component analyses.  As one of the
    component analyses, we present a novel, dynamic mutability analysis
    and show how its results can be improved by random input generation.
    Experimental results on programs of up to 185 kLOC demonstrate that,
    compared to previous approaches, our approach increases both scalability
    and overall accuracy.",
  supersededby = "ArtziKGE2007:TR",
  category = "Immutability (side effects)",
  csetags = "mernst,mernst-Immutability-(side-effects),plse",
  basefilename = "mutability-tr065",
  downloadsnonlocal =
    "https://homes.cs.washington.edu/~mernst/pubs/mutability-tr065.pdf PDF",
  csetags = "mernst,mernst-Dynamic-analysis,plse",
  summary =
   "A collection of fast, simple mutability analysis stages (both static
    and dynamic) can outperform a complex and sophisticated algorithm, in
    terms of both scalability and overall accuracy.",
  undergradCoauthor = 1,
}

@InProceedings{ArtziEKPP2006,
  author = 	 "Shay Artzi and Michael D. Ernst and Adam Kie{\.z}un and Carlos Pacheco and Jeff H. Perkins",
  authorASCII =  "Adam Kiezun",
  title = 	 "Finding the needles in the haystack: Generating legal test inputs for object-oriented programs",
  crossref =     "MTOOS2006",
  pages = 	 "27--34",
  abstract =
   "A test input for an object-oriented program typically consists of a
    sequence of method calls that use the API defined by the program
    under test. Generating legal test inputs can be challenging because,
    for some programs, the set of legal method sequences is much smaller
    than the set of all possible sequences; without a formal
    specification of legal sequences, an input generator is bound to
    produce mostly illegal sequences.
    \par
    We propose a scalable technique that combines dynamic analysis with
    random testing to help an input generator create legal test inputs
    without a formal specification, even for programs in which
    most sequences are illegal. The technique uses an example execution
    of the program to infer a model of legal call sequences, and uses
    the model to guide a random input generator towards legal but
    behaviorally-diverse sequences.
    \par
    We have implemented our technique for Java, in a tool called
    Palulu, and evaluated its effectiveness in creating legal inputs
    for real programs. Our experimental results indicate that the
    technique is effective and scalable. Our preliminary evaluation
    indicates that the technique can quickly generate legal sequences
    for complex inputs: in a case study, Palulu created legal test
    inputs in seconds for a set of complex classes, for which it took an
    expert thirty minutes to generate a single legal input.",
  basefilename = "oo-test-gen-mtoos2006",
  downloadsnonlocal =
    "https://homes.cs.washington.edu/~mernst/pubs/oo-test-gen-mtoos2006.pdf PDF",
  category = "Test generation",
  csetags = "mernst,mernst-Testing,plse",
  summary =
   "An automatically inferred model of legal method call sequences can bias test
    generation toward legal method sequences, increasing coverage and creating
    data structures beyond the ability of undirected random generation.",
}



@Misc{AnnotationsOnJavaTypes:2006aug,
  author = 	 "{Javari team}",
  title = 	 "Annotations on {Java} types",
  howpublished = "\url{https://types.cs.washington.edu/jsr308/java-annotation-design.pdf}",
  month = 	 aug,
  year = 	 2006,
  omitfromcv = 1,
}

@Misc{AnnotationsOnJavaTypes:2006sep,
  author = 	 "{Javari team}",
  title = 	 "Annotations on {Java} types",
  howpublished = "\url{https://types.cs.washington.edu/jsr308/java-annotation-design.pdf}",
  month = 	 sep,
  year = 	 2006,
  omitfromcv = 1,
}

@Misc{CustomTypeQualifiers:2006aug,
  author = 	 "Matthew M. Papi and Michael D. Ernst",
  title = 	 "Custom type qualifiers via annotations on {Java} types",
  howpublished = "\url{https://types.cs.washington.edu/jsr308/java-type-qualifiers.pdf}",
  month = 	 aug,
  year = 	 2006,
  omitfromcv = 1,
  undergradCoauthor = 1,
}

@Misc{AnnotationIndexFile:2006sep,
  author = 	 "{Javari team}",
  title = 	 "Annotation Index File Specification",
  howpublished = "\url{https://types.cs.washington.edu/jsr308/index-file-format.pdf}",
  month = 	 sep,
  year = 	 2006,
  omitfromcv = 1,
}


@Misc{JSR308-2006,
  author = 	 "Michael D. Ernst and Danny Coward",
  title = 	 "{JSR} 308: Annotations on {Java} types",
  howpublished = "\url{https://types.cs.washington.edu/jsr308/}",
  month = 	 oct # "~17,",
  year = 	 2006,
  NOabstract =   1,
  basefilename = "annotations-jsr308",
  category = "Programming language design",
  csetags = "mernst,mernst-Programming-language-design,plse",
  summary =
   "This proposal extends Java's annotation system to permit annotations on
    any use of a type (including generic type arguments, method receivers,
    etc.).",
  downloads =
    "https://checkerframework.org/jsr308/ current status and implementation;
     https://jcp.org/en/jsr/detail?id=308 original proposal",
  omitfromcv = 1,
}


@Misc{JSR308-2007-11-09,
  author = 	 "Michael D. Ernst and Danny Coward",
  title = 	 "{JSR} 308: Annotations on {Java} types",
  howpublished = "\url{https://types.cs.washington.edu/jsr308/}",
  month = 	 nov # "~9,",
  year = 	 2007,
  NOabstract =   1,
  basefilename = "annotations-jsr308",
  category = "Programming language design",
  csetags = "mernst,mernst-Programming-language-design,plse",
  summary =
   "This proposal extends Java's annotation system to permit annotations on
    any use of a type (including generic type arguments, method receivers,
    etc.).",
  downloads =
    "https://checkerframework.org/jsr308/ current status and implementation;
     https://jcp.org/en/jsr/detail?id=308 original proposal",
  omitfromcv = 1,
}


@Misc{JSR308-2007-11-12,
  author = 	 "Michael D. Ernst",
  title = 	 "Annotations on {Java} types:  {JSR} 308 working document",
  howpublished = "\url{https://types.cs.washington.edu/jsr308/}",
  month = 	 nov # "~12,",
  year = 	 2007,
  NOabstract =   1,
  basefilename = "annotations-jsr308",
  category = "Programming language design",
  csetags = "mernst,mernst-Programming-language-design,plse",
  summary =
   "This proposal extends Java's annotation system to permit annotations on
    any use of a type (including generic type arguments, method receivers,
    etc.).",
  downloads =
    "https://checkerframework.org/jsr308/ current status and implementation;
     https://jcp.org/en/jsr/detail?id=308 original proposal",
  omitfromcv = 1,
}


@Misc{JSR308-2008-09-12,
  author = 	 "Michael D. Ernst",
  title = 	 "{Type Annotations} specification ({JSR} 308)",
  OLDhowpublished = "\url{https://types.cs.washington.edu/jsr308/}",
  howpublished = "\url{https://checkerframework.org/jsr308/}",
  month = 	 sep # "~12,",
  year = 	 2008,
  NOabstract =   1,
  basefilename = "annotations-jsr308",
  category = "Programming language design",
  csetags = "mernst,mernst-Programming-language-design,plse",
  summary =
   "This specification extends Java's annotation system to permit annotations
    on any use of a type (including generic type arguments, method receivers,
    etc.).  It is planned for inclusion in Java 7, but it is usable immediately
    with full backward compatibility with existing compilers and JVMs.",
  downloads =
    "https://checkerframework.org/jsr308/ current status and implementation;
     https://jcp.org/en/jsr/detail?id=308 original proposal",
  omitfromcv = 1,
}


@Misc{JSR308-2013-10,
  author = 	 "Michael D. Ernst",
  title = 	 "{Type Annotations} specification ({JSR} 308)",
  howpublished = "\url{https://types.cs.washington.edu/jsr308/}",
  month = 	 oct,
  year = 	 2013,
  NOabstract =   1,
  basefilename = "annotations-jsr308",
  category = "Programming language design",
  csetags = "mernst,mernst-Programming-language-design,plse",
  summary =
   "This specification extends Java's annotation system to permit annotations
    on any use of a type (including generic type arguments, method receivers,
    etc.).  It is planned for inclusion in Java 8, but it is usable immediately
    with full backward compatibility with existing compilers and JVMs.",
  downloads =
    "https://checkerframework.org/jsr308/ current status and implementation;
     https://jcp.org/en/jsr/detail?id=308 original proposal",
  omitfromcv = 1,
}


@Misc{JSR308-webpage-201110,
  author = 	 "Michael D. Ernst",
  title = 	 "{Type Annotations} specification ({JSR} 308)",
  howpublished = "\url{https://checkerframework.org/jsr308/}",
  month =        oct,
  year = 	 2011,
  NOabstract =   1,
  basefilename = "annotations-jsr308",
  category = "Programming language design",
  csetags = "mernst,mernst-Programming-language-design,plse",
  summary =
   "This specification extends Java's annotation system to permit annotations
    on any use of a type (including generic type arguments, method receivers,
    etc.).  It is planned for inclusion in Java 7, but it is usable immediately
    with full backward compatibility with existing compilers and JVMs.",
  downloads =
    "https://checkerframework.org/jsr308/ current status and implementation;
     https://jcp.org/en/jsr/detail?id=308 original proposal",
  omitfromcv = 1,
}


@Misc{JSR308-webpage-201310,
  author = 	 "Michael D. Ernst",
  title = 	 "{Type Annotations} specification ({JSR} 308)",
  howpublished = "\url{https://checkerframework.org/jsr308/}",
  month =        oct,
  year = 	 2013,
  NOabstract =   1,
  basefilename = "annotations-jsr308",
  category = "Programming language design",
  csetags = "mernst,mernst-Programming-language-design,plse",
  summary =
   "This specification extends Java's annotation system to permit annotations
    on any use of a type (including generic type arguments, method receivers,
    etc.).  It is planned for inclusion in Java 8, but it is usable immediately
    with full backward compatibility with existing compilers and JVMs.",
  downloads =
    "https://checkerframework.org/jsr308/ current status and implementation;
     https://jcp.org/en/jsr/detail?id=308 original proposal",
  omitfromcv = 1,
}


@TechReport{McCamantE2006:TR,
  author = 	 {Stephen McCamant and Michael D. Ernst},
  title = 	 {Quantitative information-flow tracking for {C} and related languages},
  institution =  MITCSAIL,
  year = 	 2006,
  number =	 "MIT-CSAIL-TR-2006-076",
  address =	 MITaddr,
  month =	 nov # "~17,",
  abstract =
   "We present a new approach for tracking programs' use of data through
    arbitrary calculations, to determine how much information about secret
    inputs is revealed by public outputs.
    Using a fine-grained dynamic bit-tracking analysis, the technique
    measures the information revealed during a particular execution.
    The technique accounts for indirect flows, e.g.\ via branches and pointer
    operations.
    Two kinds of untrusted annotation improve the precision of the analysis.
    An implementation of the technique based on dynamic binary translation
    is demonstrated on real C, C++, and Objective C programs of up to half
    a million lines of code.
    In case studies, the tool checked multiple security
    policies, including one that was violated by a previously unknown bug.",
  basefilename = "secret-tracking-tr076",
  category = "Security",
  csetags = "mernst,mernst-Security,plse",
  supersededby = "McCamantE2007:TR",
  summary =
   "This report presents a novel dynamic instrumentation
    technique to measure how much information about a program's secret
    inputs is revealed in its public outputs. By operating at the binary
    level and requiring minimal annotation, the technique scales to real
    programs of more than 500 KLOC.",
  downloadsnonlocal =
   "https://groups.csail.mit.edu/pag/pubs/secret-tracking-tr076.pdf PDF;
    https://dspace.mit.edu/handle/1721.1/34892 DSpace",
}


@InCollection{Ernst2006,
  author = 	 "Michael D. Ernst",
  title = 	 "The {Groupthink} specification exercise",
  crossref = 	 "ICSE2005education",
  pages = 	 "89--107",
  publisher =    "Springer",
  year = 	 2006,
  month =        dec,
  OMITeditor = 	 "Mehdi Jazayeri and Paola Inverardi",
  volume = 	 4309,
  series = 	 LNCS,
  abstract =
   "Teaching students to read and write specifications is difficult.  It is
    even more difficult to motivate specifications{\,---\,}to convince
    students of the value of specifications and make students eager to use
    them.  The Groupthink specification exercise aims to fulfill all these
    goals.  Groupthink is a fun group activity, in the style of a game show,
    that teaches students about teamwork, communication, and specifications.
    This exercise teaches students how difficult it is to write an effective
    specification (determining what needs to be specified, making the
    choices, and capturing those choices), techniques for getting them right,
    and criteria for evaluating them.  It also gives students practice in
    doing so, in a fun environment that is conducive to learning.
    Specifications are used not as an end in themselves, but as a means to
    solving realistic problems that involve understanding system behavior.
    \par
    Students enjoy the activity, and it improves their ability to read and
    write specifications.  The two-hour, low-prep activity is self-contained,
    scales from classes of ten to hundreds of students, and can be split into
    2 one-hour sessions or integrated into an existing curriculum.  It is
    freely available from the author (\texttt{mernst@cs.washington.edu}), complete
    with lecture slides, handouts, a scoring spreadsheet, and optional
    software.  Instructors outside MIT have successfully used the materials.",
  basefilename = "groupthink-2006",
  downloadsnonlocal =
    "https://homes.cs.washington.edu/~mernst/pubs/groupthink-2006.pdf PDF;
     https://homes.cs.washington.edu/~mernst/pubs/groupthink-2006-2up.pdf 2-up PDF",
  downloads =
   "https://homes.cs.washington.edu/~mernst/pubs/groupthink-specification-exercise.zip activity materials;
    https://homes.cs.washington.edu/~mernst/software/UpopVote.zip optional voting software;
    https://homes.cs.washington.edu/~mernst/pubs/groupthink-icse2005-slides.pdf ICSE 2005 slides (PDF);
    https://homes.cs.washington.edu/~mernst/pubs/groupthink-icse2005-slides.ppt ICSE 2005 slides (PowerPoint)",
  OLDdownloads =
    "https://vital.cs.ohiou.edu/vitalwiki/index.php/Aid_for_Groupthink Second Life version",
  category = "Education",
  csetags = "mernst,mernst-Software-engineering,plse",
  summary =
   "The Groupthink specification exercise is a fun group activity that
    teaches students about specifications, teamwork, and communication.
    This paper describes both the goals of the activity (along with an
    assessment of it), and the mechanics of how to run it.",
}



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%% 2007
%%%


@InProceedings{KiezunETF2007,
  author = 	 "Adam Kie{\.z}un and Michael D. Ernst and Frank Tip and Robert M. Fuhrer",
  authorASCII =  "Adam Kiezun",
  title = 	 "Refactoring for parameterizing {Java} classes",
  crossref =     "ICSE2007",
  pages = 	 "437--446",
  abstract =
   "Type safety and expressiveness of many existing Java libraries and their
    client applications would improve, if the libraries were upgraded to define
    generic classes.  Efficient and accurate tools exist to assist client
    applications to use generic libraries, but so far the libraries themselves
    must be parameterized manually, which is a tedious, time-consuming, and
    error-prone task.  We present a type-constraint-based algorithm for
    converting non-generic libraries to add type parameters.  The algorithm
    handles the full Java language and preserves backward compatibility, thus
    making it safe for existing clients.  Among other features, it is capable
    of inferring wildcard types and introducing type parameters for
    mutually-dependent classes.  We have implemented the algorithm as a fully
    automatic refactoring in Eclipse.
    \par
    We evaluated our work in two ways.  First, our tool parameterized code that
    was lacking type parameters.  We contacted the developers of several of
    these applications, and in all cases they
    confirmed that the resulting parameterizations were correct and useful.
    Second, to better quantify its effectiveness, our tool parameterized
    classes from already-generic libraries, and we compared the results to
    those that were created by the libraries' authors.  Our tool performed the
    refactoring accurately---in 87\% of cases the results were as good as those
    created manually by a human expert, in 9\% of cases the tool results were
    better, and in 4\% of cases the tool results were worse.",
  basefilename = "parameterizing-generics-icse2007",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/parameterizing-generics-icse2007.pdf PDF;
    https://homes.cs.washington.edu/~mernst/pubs/parameterizing-generics-icse2007-slides.pdf slides (PDF)",
  category = "Refactoring",
  csetags = "mernst,mernst-Refactoring,plse",
  summary =
   "Programmers must change their programs to take advantage of generic types.
    This paper presents a type-constraint-based analysis that converts
    non-generic classes such as List into generic classes such as List<T>.",
}


@InProceedings{PachecoLEB2007,
  author = 	 "Carlos Pacheco and Shuvendu K. Lahiri and Michael D. Ernst and Thomas Ball",
  title = 	 "Feedback-directed random test generation",
  crossref =     "ICSE2007",
  pages = 	 "75--84",
  abstract =
   "We present a technique that improves random test generation by
    incorporating feedback obtained from executing test inputs as they are
    created. Our technique builds inputs incrementally by randomly selecting a
    method call to apply and finding arguments from among
    previously-constructed inputs. As soon as an input is built, it is executed
    and checked against a set of contracts and filters. The result of the
    execution determines whether the input is redundant, illegal,
    contract-violating, or useful for generating more inputs. The technique
    outputs a test suite consisting of unit tests for the classes under
    test. Passing tests can be used to ensure that code contracts are preserved
    across program changes; failing tests (that violate one or more contract)
    point to potential errors that should be corrected.
    \par
    Our experimental results indicate that feedback-directed random test
    generation can outperform systematic and undirected random test generation,
    in terms of coverage and error detection. On four small but nontrivial data
    structures (used previously in the literature), our technique achieves
    higher or equal block and predicate coverage than model checking (with and
    without abstraction) and undirected random generation. On 14 large,
    widely-used libraries (comprising 780KLOC), feedback-directed random test
    generation finds many previously-unknown errors, not found by either model
    checking or undirected random generation.",
  basefilename = "feedback-testgen-icse2007",
  downloads =
   "https://homes.cs.washington.edu/~mernst/pubs/feedback-testgen-issta2008-slides.pptx ISSTA'08 slides (PowerPoint);
    https://homes.cs.washington.edu/~mernst/pubs/feedback-testgen-icse2017-mip-slides.pdf ICSE 2017 retrospective slides (PDF);
    https://homes.cs.washington.edu/~mernst/pubs/feedback-testgen-icse2017-mip-slides.pptx ICSE 2017 retrospective slides (PowerPoint);
    https://randoop.github.io/randoop/ Randoop implementation",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/feedback-testgen-icse2007.pdf PDF;
    https://homes.cs.washington.edu/~mernst/pubs/feedback-testgen-icse2007-slides.pdf slides (PDF);
    https://homes.cs.washington.edu/~mernst/pubs/feedback-testgen-icse2007-slides.ppt slides (PowerPoint)",
  category = "Test generation",
  csetags = "mernst,mernst-Testing,plse",
  summary =
   "This paper presents a technique that improves random test generation by
    incorporating feedback from executing previously-generated inputs.  The
    technique found serious, previously-unknown errors in widely-deployed
    applications.",
}


@InProceedings{Ernst2017:RandoopRetrospective,
  author = 	 "Michael D. Ernst",
  title = 	 "Retrospective: Feedback-directed Random Test Generation",
  crossref =  "ICSE2017",
  note = 	 "{ICSE} 2007 Most Influential Paper talk",
  omitfromcv = "*",
  supersededby = "PachecoLEB2007",
}

@Misc{Randoop-manual-2.1.1,
  author = 	 "{Randoop Developers}",
  title = 	 "Randoop Manual",
  howpublished = "\url{https://randoop.github.io/randoop/manual/}",
  month = 	 jan,
  year = 	 2016,
  note = 	 "Version 2.1.1",
  omitfromcv = 1,
}


@InProceedings{KimE2007:MSR2007,
  author = 	 "Sunghun Kim and Michael D. Ernst",
  title = 	 "Prioritizing warnings by analyzing software history",
  crossref =     "MSR2007",
  pages = 	 "27--30",
  abstract =
   "Automatic bug finding tools tend to have high false positive rates: most
    warnings do not indicate real bugs.  Usually bug finding tools prioritize
    each warning category (such as the priority of ``overflow'' is 1 or the
    priority of ``jumbled incremental'' is 3), but the tools' prioritization is
    not very effective.
    \par
    In this paper, we prioritize warning categories by analyzing the software
    change history. The underlying intuition is that if warnings from a
    category are resolved quickly by developers, the warnings in the category
    are important. Experiments with three bug finding tools (FindBugs, Jlint,
    and PMD) and two open source projects (Columba and jEdit) indicate that
    different warning categories have very different lifetimes. Based on that
    observation, we propose a preliminary algorithm for warning category
    prioritizing.",
  basefilename = "prioritize-warnings-msr2007",
  downloadsnonlocal =
    "https://homes.cs.washington.edu/~mernst/pubs/prioritize-warnings-msr2007.pdf PDF",
  category = "Defect prediction",
  csetags = "mernst,mernst-Bug-prediction,plse",
  summary =
   "Bug-finding tools prioritize their warning messages, but often do so poorly.
    This paper gives a new prioritization, based on which problems programmers
    have fixed most quickly in the past --- those are likely to be the most
    important ones."
}





@TechReport{ZibinPAKE2007:TR,
  author = 	 "Yoav Zibin and Alex Potanin and Shay Artzi and Adam Kie{\.z}un and Michael D. Ernst",
  authorASCII =  "Adam Kiezun",
  title = 	 "Object and reference immutability using {Java} generics",
  institution =  MITCSAIL,
  year = 	 2007,
  number = 	 "MIT-CSAIL-TR-2007-018",
  address = 	 MITaddr,
  month = 	 mar # "~16,",
  abstract =
   "This paper presents \emph{Immutability Generic Java} (IGJ), a novel
    language extension that expresses immutability without changing Java's
    syntax by building upon Java's generics and annotation mechanisms.  In
    IGJ, each class has one additional generic parameter that is
    \texttt{Immutable}, \texttt{Mutable}, or \texttt{ReadOnly}.  IGJ guarantees both
    \emph{reference immutability} (only mutable references can mutate an
    object) and \emph{object immutability} (an immutable reference points
    to an immutable object).  IGJ is the first proposal for enforcing
    object immutability, and its reference immutability is more expressive
    than previous work.  IGJ also permits covariant changes of generic
    arguments in a type-safe manner, e.g., a readonly list of integers is a
    subtype of a readonly list of numbers.  IGJ extends Java's type system
    with a few simple rules.  We formalize this type system and prove it
    sound.  Our IGJ compiler works by type-erasure and generates byte-code
    that can be executed on any JVM without runtime penalty.",
  supersededby = "ZibinPAAKE2007",
  basefilename = "immutability-generics-tr018",
  downloadsnonlocal =
    "https://homes.cs.washington.edu/~mernst/pubs/immutability-generics-tr018.pdf PDF",
  category = "Immutability (side effects)",
  OMITcsetagsBECAUSESUPERSEDED = "mernst,mernst-Immutability-(side-effects),plse",
  summary =
   "This paper shows how to provide compiler-checked guarantees of both
   object immutability and reference immutability, without changes to Java
   syntax, by providing a single ``immutability'' generic parameter for
   each class.",
}



@TechReport{ArtziKGE2007:TR,
  author = 	 "Shay Artzi and Adam Kie{\.z}un and David Glasser and Michael D. Ernst",
  authorASCII =  "Adam Kiezun",
  title = 	 "Combined static and dynamic mutability analysis",
  institution =  MITCSAIL,
  year = 	 2007,
  number = 	 "MIT-CSAIL-TR-2007-020",
  address = 	 MITaddr,
  month = 	 mar # "~23,",
  abstract =
   "Knowing which method parameters may be mutated during a method's execution
    is useful for many software engineering tasks.  We present an approach to
    discovering parameter immutability, in which several lightweight, scalable
    analyses are combined in stages, with each stage refining the overall
    result.  The resulting analysis is scalable and combines the strengths of
    its component analyses.  As one of the component analyses, we present a
    novel, dynamic mutability analysis and show how its results can be improved
    by random input generation.  Experimental results on programs of up to 185
    kLOC show that, compared to previous approaches, our approach increases
    both scalability and overall accuracy.",
  supersededby = "ArtziKGE2007",
  basefilename = "mutability-tr020",
  downloadsnonlocal =
    "https://homes.cs.washington.edu/~mernst/pubs/mutability-tr020.pdf PDF",
  category = "Immutability (side effects)",
  OMITcsetagsBECAUSESUPERSEDED = "mernst,mernst-Immutability-(side-effects),plse",
  summary =
   "A collection of fast, simple mutability analysis stages (both static
    and dynamic) can outperform a complex and sophisticated algorithm, in
    terms of both scalability and overall accuracy.",
  undergradCoauthor = 1,
}


@InProceedings{McCamantE2007,
  author = 	 "Stephen McCamant and Michael D. Ernst",
  title = 	 "A simulation-based proof technique for dynamic information flow",
  crossref =     "PLAS2007",
  pages = 	 "41--46",
  abstract =
   "Information-flow analysis can prevent programs from improperly
    revealing secret information, and a dynamic approach can make such
    analysis more practical, but there has been relatively little work
    verifying that such analyses are sound (account for all flows in a
    given execution).  We describe a new technique for proving the
    soundness of dynamic information-flow analyses for policies such
    as end-to-end confidentiality.  The proof technique simulates the
    behavior of the analyzed program with a pair of copies of the
    program: one has access to the secret information, and the other
    is responsible for output.  The two copies are connected by a
    limited-bandwidth communication channel, and the amount of
    information passed on the channel bounds the amount of information
    disclosed, allowing it to be quantified.  We illustrate the
    technique by application to a model of a practical checking tool
    based on binary instrumentation, which had not previously been
    shown to be sound.",
  basefilename = "infoflow-proof-plas2007",
  downloadsnonlocal =
   "https://groups.csail.mit.edu/pag/pubs/infoflow-proof-plas2007.pdf PDF",
  category = "Security",
  csetags = "mernst,mernst-Security,plse",
  summary =
   "A dynamic analysis of information flow (e.g., end-to-end confidentiality) is
    sound if its estimates of the amount of information revealed can never be
    too low.  This paper proves such a soundness result by simulating an analyzed
    program with a pair of copies connected by a limited-bandwidth channel.",
}


@InProceedings{ZibinPAAKE2007,
  author = 	 "Yoav Zibin and Alex Potanin and Mahmood Ali and Shay Artzi and Adam Kie{\.z}un and Michael D. Ernst",
  authorASCII =  "Adam Kiezun",
  pseudoauthor = "Matthew M. Papi",
  title = 	 "Object and reference immutability using {Java} generics",
  crossref =     "FSE2007",
  pages = 	 "75--84",
  abstract =
   "A compiler-checked immutability guarantee provides useful documentation,
    facilitates reasoning, and enables optimizations.  This paper presents
    \emph{Immutability Generic Java} (IGJ), a novel language extension that
    expresses immutability without changing Java's syntax by building upon
    Java's generics and annotation mechanisms.  In IGJ, each class has one
    additional type parameter that is \texttt{Mutable}, \texttt{Immutable}, or
    \texttt{ReadOnly}.  IGJ guarantees both \emph{reference immutability} (only
    mutable references can mutate an object) and \emph{object immutability} (an
    immutable reference points to an immutable object).  IGJ is the first
    proposal for enforcing object immutability within Java's syntax and type
    system, and its reference immutability is more expressive than previous
    work.  IGJ also permits covariant changes of type parameters in a type-safe
    manner, e.g., a readonly list of integers is a subtype of a readonly list
    of numbers.  IGJ extends Java's type system with a few simple rules.  We
    formalize this type system and prove it sound.  Our IGJ compiler works by
    type-erasure and generates byte-code that can be executed on any JVM
    without runtime penalty.",
  basefilename = "immutability-generics-fse2007",
  downloads =
   "https://checkerframework.org/manual/#igj-checker IGJ implementation",
  downloadsnonlocal =
    "https://homes.cs.washington.edu/~mernst/pubs/immutability-generics-fse2007.pdf PDF",
  category = "Immutability (side effects)",
  csetags = "mernst,mernst-Immutability-(side-effects),plse",
  summary =
   "This paper shows how to provide compiler-checked guarantees of both
   object immutability and reference immutability, without changes to Java
   syntax, by providing a single ``immutability'' generic parameter for
   each class.",
  undergradCoauthor = 1,
}


@InProceedings{KimE2007,
  author = 	 "Sunghun Kim and Michael D. Ernst",
  title = 	 "Which warnings should {I} fix first?",
  crossref =     "FSE2007",
  pages = 	 "45--54",
  abstract =
   "Automatic bug-finding tools have a high false positive rate: most
    warnings do not indicate real bugs. Usually bug-finding tools
    assign important warnings high priority. However, the
    prioritization of tools tends to be ineffective. We observed the
    warnings output by three bug-finding tools, FindBugs, Jlint, and
    PMD, for three subject programs, Columba, Lucene, and Scarab.
    Only 6\%, 9\%, and 9\% of warnings are removed by bug fix
    changes during 1 to 4 years of the software development. About
    90\% of warnings remain in the program or are removed during
    non-fix changes --- likely false positive warnings. The tools'
    warning prioritization is little help in focusing on important
    warnings: the maximum possible precision by selecting high-priority
    warning instances is only 3\%, 12\%, and 8\% respectively.
    \par
    In this paper, we propose a history-based warning prioritization
    algorithm by mining warning fix experience that is recorded in
    the software change history. The underlying intuition is that if
    warnings from a category are eliminated by fix-changes, the
    warnings are important. Our prioritization algorithm improves
    warning precision to 17\%, 25\%, and 67\% respectively.",
  basefilename = "prioritize-warnings-fse2007",
  downloadsnonlocal =
    "https://homes.cs.washington.edu/~mernst/pubs/prioritize-warnings-fse2007.pdf PDF",
  category = "Defect prediction",
  csetags = "mernst,mernst-Bug-prediction,plse",
  summary =
   "This paper determines how a bug-finding tool should prioritize its warnings.
    The prioritization is computed from the bug fix history of the program ---
    the problems programmers considered important enough to fix.",
}


@TechReport{PapiACPE2007:TR,
  author = 	 "Matthew M. Papi and Mahmood Ali and Telmo Luis {Correa~Jr.} and Jeff H. Perkins and Michael D. Ernst",
  title = 	 "Pluggable type-checking for custom type qualifiers in {Java}",
  institution =  MITCSAIL,
  year = 	 2007,
  number = 	 "MIT-CSAIL-TR-2007-047",
  address = 	 MITaddr,
  month = 	 sep # "~17,",
  abstract =
   "We have created a framework for adding custom type qualifiers to the Java
    language in a backward-compatible way.  The type system designer defines
    the qualifiers and creates a compiler plug-in that enforces their
    semantics.  Programmers can write the type qualifiers in their programs
    and be informed of errors or assured that the program is free of those
    errors.  The system builds on existing Java tools and APIs.
    \par
    In order to evaluate our framework, we have written four type-checkers
    using the framework:  for a non-null type system that can detect and
    prevent null pointer errors; for an interned type system that can detect
    and prevent equality-checking errors; for a reference immutability type
    system, Javari, that can detect and prevent mutation errors; and for a
    reference and object immutability type system, IGJ, that can detect and
    prevent even more mutation errors.  We have conducted case studies using
    each checker to find real errors in existing software.  These case
    studies demonstrate that the checkers and the framework
    are practical and useful.",
  usesDaikonAsTestSubject = 1,
  basefilename = "custom-types-tr047",
  downloadsnonlocal =
    "https://homes.cs.washington.edu/~mernst/pubs/custom-types-tr047.pdf PDF",
  supersededby = "PapiACPE2008",
  category = "Programming language design",
  OMITcsetagsBECAUSESUPERSEDED = "mernst,mernst-Programming-language-design,plse",
  summary =
   "We have created a framework for adding custom type qualifiers to the Java
    language in a backward-compatible way, have built four type-checkers
    using the framework, and have conducted cases studies using each checker
    to find real errors in existing software.",
  undergradCoauthor = 1,
}


@InProceedings{CorreaQE2007,
  author = 	 "Telmo Luis {Correa~Jr.} and Jaime Quinonez and Michael D. Ernst",
  title = 	 "Tools for enforcing and inferring reference immutability in {Java}",
  crossref =     "OOPSLACompanion2007",
  pages = 	 "866--867",
  abstract =
   "Accidental mutation is a major source of difficult-to-detect errors in
    object-oriented programs.  We have built tools that detect and prevent such
    errors.  The tools include a javac plug-in that enforces the Javari type
    system, and a type inference tool. The system is fully compatible with
    existing Java programs.",
  basefilename = "refimmut-tools-oopsla2007",
  downloads =
   "https://types.cs.washington.edu/javari/ Javari implementation",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/refimmut-tools-oopsla2007.pdf PDF",
  supersededby = "QuinonezTE2008 A tool description",
  category = "Immutability (side effects)",
  csetags = "mernst,mernst-Immutability-(side-effects),plse",
  summary =
   "The Javari language for reference immutability helps Java programmers avoid
    accidental mutation errors.  This paper describes two tools that implement
    Javari --- a type checker and a type inference system.",
  undergradCoauthor = 1,
}

@InProceedings{PapiE2007,
  author = 	 "Matthew M. Papi and Michael D. Ernst",
  title = 	 "Compile-time type-checking for custom type qualifiers in {Java}",
  crossref =     "OOPSLACompanion2007",
  pages = 	 "809--810",
  abstract =
   "We have created a system that enables programmers to add custom type
    qualifiers to the Java language in a backward-compatible way.  The system
    allows programmers to write type qualifiers in their programs and to create
    compiler plug-ins that enforce the semantics of these qualifiers at compile
    time.  The system builds on existing Java tools and APIs, and on JSR 308.
    \par
    As an example, we introduce a plug-in to Sun's Java compiler that uses our
    system to type-check the NonNull qualifier.  Programmers can use the
    {\tt @NonNull} annotation to prohibit an object reference from being null;
    then, by invoking a Java compiler with the NonNull plug-in, they can check
    for NonNull errors at compile time and rid their programs of null-pointer
    exceptions.",
  basefilename = "typequals-demo-oopsla2007",
  downloads =
   "https://checkerframework.org/ Checker Framework implementation",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/typequals-demo-oopsla2007.pdf PDF",
  supersededby = "PapiACPE2008 A tool description",
  category = "Programming language design",
  OMITcsetagsBECAUSESUPERSEDED = "mernst,mernst-Programming-language-design,plse",
  summary =
   "User-defined type qualifiers enable programmers to state program properties
    and to check them at compile time.  This paper describes a system for
    building custom type qualifiers, and several type qualifiers built with it.",
  undergradCoauthor = 1,
}



@InProceedings{PachecoE2007,
  author = 	 "Carlos Pacheco and Michael D. Ernst",
  title = 	 "Randoop: Feedback-directed random testing for {Java}",
  crossref =     "OOPSLACompanion2007",
  pages = 	 "815--816",
  abstract =
   "Randoop for Java is a tool that generates unit tests for Java code
    using feedback-directed random test generation. This paper describes
    Randoop's input, output, and test generation algorithm. We also give an
    overview of Randoop's annotation-based interface for specifying
    configuration parameters that affect Randoop's behavior and output.",
  basefilename = "pacheco-randoop-oopsla2007",
  downloads =
   "https://randoop.github.io/randoop/ Randoop implementation",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/pacheco-randoop-oopsla2007.pdf PDF",
  supersededby = "PachecoLEB2007 A tool description",
  category = "Test generation",
  OMITcsetagsBECAUSESUPERSEDED = "mernst,mernst-Testing,plse",
  summary =
   "This paper describes the Randoop tool for automatically generating unit
    tests for Java programs.  Randoop uses the feedback-directed test
    generation technique of Pacheco et al.'s ICSE 2007 paper.",
}



@InProceedings{ArtziKGE2007,
  author = 	 "Shay Artzi and Adam Kie{\.z}un and David Glasser and Michael D. Ernst",
  authorASCII =	 "Shay Artzi and Adam Kiezun and David Glasser and Michael D. Ernst",
  title = 	 "Combined static and dynamic mutability analysis",
  crossref =     "ASE2007",
  pages = 	 "104--113",
  abstract =
   "Knowing which method parameters may be mutated during a method's execution
    is useful for many software engineering tasks.  We present an approach to
    discovering parameter reference immutability, in which several lightweight,
    scalable analyses are combined in stages, with each stage refining the
    overall result.  The resulting analysis is scalable and combines the
    strengths of its component analyses.  As one of the component analyses, we
    present a novel, dynamic mutability analysis and show how its results can
    be improved by random input generation.  Experimental results on programs
    of up to 185 kLOC show that, compared to previous approaches, our approach
    increases both scalability and overall accuracy.",
  basefilename = "mutability-ase2007",
  downloadsnonlocal =
    "https://homes.cs.washington.edu/~mernst/pubs/mutability-ase2007.pdf PDF",
  supersededby = "ArtziQKE2009",
  category = "Immutability (side effects)",
  OMITcsetagsBECAUSESUPERSEDED = "mernst,mernst-Immutability-(side-effects),plse",
  summary =
   "A collection of fast, simple mutability analysis stages (both static
    and dynamic) can outperform a complex and sophisticated algorithm, in
    terms of both scalability and overall accuracy.",
  undergradCoauthor = 1,
}


@TechReport{KimAE2007,
  author = 	 "Sunghun Kim and Shay Artzi and Michael D. Ernst",
  title = 	 "ReCrash: Making crashes reproducible",
  institution =  MITCSAIL,
  year = 	 2007,
  number = 	 "MIT-CSAIL-TR-2007-054",
  address = 	 MITaddr,
  month = 	 nov # "~20,",
  supersededby = "ArtziKE2008",
  abstract =
   "It is difficult to fix a problem without being able to reproduce it.
    However, reproducing a problem is often difficult and time-consuming.  This
    paper proposes a novel algorithm, ReCrash, that generates multiple unit
    tests that reproduce a given program crash.  ReCrash dynamically tracks
    method calls during every execution of the target program.  If the program
    crashes, ReCrash saves information about the relevant method calls and uses
    the saved information to create unit tests reproducing the crash.
    \par
    We present ReCrashJ, an implementation of ReCrash for Java. ReCrashJ
    reproduced real crashes from javac, SVNKit, Eclipse JDT, and BST\@.
    ReCrashJ is efficient, incurring 13\%--64\% performance overhead.  If this
    overhead is unacceptable, then ReCrashJ has another mode that has
    negligible overhead until a crash occurs and 0\%--1.7\% overhead until a
    second crash, at which point the test cases are generated.",
  basefilename = "repro-crashes-tr054",
  downloads = "https://groups.csail.mit.edu/pag/reCrash/ ReCrash implementation",
  downloadsnonlocal =
   "https://groups.csail.mit.edu/pag/pubs/repro-crashes-tr054.pdf PDF;
    https://dspace.mit.edu/handle/1721.1/39639 DSpace",
  category = "Debugging,Test generation",
  OMITcsetagsBECAUSESUPERSEDED = "mernst,mernst-Testing,plse",
  summary =
   "ReCrash is a lightweight technique that monitors a program for errors
    such as crashes.  When such an error occurs, ReCrash creates multiple
    unit tests that reproduce it.  This eases debugging and fixing the errors.",
}

@TechReport{McCamantE2007:TR,
  author = 	 "Stephen McCamant and Michael D. Ernst",
  title = 	 "Quantitative information flow as network flow capacity",
  institution =  MITCSAIL,
  year = 	 2007,
  number = 	 "MIT-CSAIL-TR-2007-057",
  address = 	 MITaddr,
  month = 	 dec # "~10,",
  abstract =
   "We present a new technique for determining how much information about
    a program's secret inputs is revealed by its public outputs.  In
    contrast to previous techniques based on reachability from secret
    inputs (tainting), it achieves a more precise quantitative result by
    computing a maximum flow of information between the inputs and
    outputs.  The technique uses static control-flow regions to soundly
    account for implicit flows via branches and pointer operations, but
    operates dynamically by observing one or more program executions and
    giving numeric flow bounds specific to them (e.g., ``17 bits'').  The
    maximum flow in a network also gives a minimum cut (a set of edges
    that separate the secret input from the output), which can be used to
    efficiently check that the same policy is satisfied on future
    executions.  We performed case studies on 5 real C, C++, and Objective
    C programs, 3 of which had more than 250K lines of code.  The tool
    checked multiple security policies, including one that was violated by
    a previously unknown bug.",
  basefilename = "secret-max-flow-tr057",
  downloadsnonlocal =
   "https://groups.csail.mit.edu/pag/pubs/secret-max-flow-tr057.pdf PDF;
    https://dspace.mit.edu/handle/1721.1/39812 DSpace",
  supersededby = "McCamantE2008",
  category = "Security",
  OMITcsetagsBECAUSESUPERSEDED = "mernst,mernst-Security,plse",
  summary =
   "To obtain a more precise measurement of the amount of secret information
    a program might reveal, we replace the usual technique of tainting
    (reachability from secret inputs) with a maximum-flow computation on
    a graph representation of execution with edge capacities. With
    appropriate optimizations, the technique scales to check realistic
    properties in several large C programs.",
}


@Article{ErnstPGMPTX2007,
  author =	 "Michael D. Ernst and Jeff H. Perkins and Philip J. Guo
                  and Stephen McCamant and Carlos Pacheco
                  and Matthew S. Tschantz and Chen Xiao",
  title =	 "The {Daikon} system for dynamic detection of likely invariants",
  journal = 	 SCP,
  year = 	 2007,
  volume = 	 69,
  number = 	 "1--3",
  pages = 	 "35--45",
  month = 	 dec,
  abstract =
   "Daikon is an implementation of dynamic detection of likely invariants;
    that is, the Daikon invariant detector reports likely program
    invariants.  An invariant is a property that holds at a certain point
    or points in a program; these are often used in assert statements,
    documentation, and formal specifications.   Examples
    include being constant ($x = a$), non-zero ($x \ne 0$), being
    in a range ($a \le x \le b$), linear relationships ($y =
    ax+b$), ordering ($x \le y$), functions from a library ($x =
    \mathrm{fn}(y)$), containment ($x \in y$), sortedness ($x\
    \mathrm{is}\ \mathrm{sorted}$), and many more.  Users can extend Daikon
    to check for additional invariants.
    \par
    Dynamic invariant detection runs a program, observes the values
    that the program computes, and then reports properties that were
    true over the observed executions.  Dynamic invariant detection is
    a machine learning technique that can be applied to arbitrary
    data.  Daikon can detect invariants in C, C + +, Java, and Perl
    programs, and in record-structured data sources; it is easy to
    extend Daikon to other applications.
    \par
    Invariants can be useful in program understanding and a host of other
    applications.
    Daikon's output has been used for generating test cases, predicting
    incompatibilities in component integration, automating
    theorem-proving, repairing inconsistent data structures, and checking
    the validity of data streams, among other tasks.
    \par
    Daikon is freely available in source and binary form, along with
    extensive documentation, at \url{https://plse.cs.washington.edu/daikon/}.",
  basefilename = "daikon-tool-scp2007",
  downloads = "https://plse.cs.washington.edu/daikon/ Daikon implementation",
  downloadsnonlocal =
    "https://homes.cs.washington.edu/~mernst/pubs/daikon-tool-scp2007.pdf PDF",
  category = "Specification inference",
  csetags = "mernst,mernst-Invariant-detection,plse",
  summary =
   "This paper discusses the Daikon tool, including its features,
    applications, architecture, and development process.  It is not a paper
    about dynamic invariant detection per se.",
  undergradCoauthor = 1,
}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%% 2008
%%%


@TechReport{SaffBE2008,
  author = 	 "David Saff and Marat Boshernitsan and Michael D. Ernst",
  title = 	 "Theories in practice:  Easy-to-write specifications that catch bugs",
  institution =  MITCSAIL,
  year = 	 2008,
  number = 	 "MIT-CSAIL-TR-2008-002",
  address = 	 MITaddr,
  month = 	 jan # "~14,",
  abstract =
   "Automated testing during development helps ensure that software works
    according to the test suite.  Traditional test suites verify a few
    well-picked scenarios or example inputs.  However, such example-based
    testing does not uncover errors in legal inputs that the test writer
    overlooked.  We propose \emph{theory-based testing} as an adjunct to
    example-based testing.  A theory generalizes a (possibly infinite) set of
    example-based tests.  A theory is an assertion that should be true for
    any data, and it can be exercised by human-chosen data or by automatic
    data generation.  A theory is expressed in an ordinary programming
    language, it is easy for developers to use (often even easier than
    example-based testing), and it serves as a lightweight form of
    specification.  Six case studies demonstrate the utility of theories that
    generalize existing tests to prevent bugs, clarify intentions, and reveal
    design problems.",
  basefilename = "testing-theories-tr002",
  OPTdownloads = "",
  downloadsnonlocal =
   "https://dspace.mit.edu/bitstream/handle/1721.1/40090/MIT-CSAIL-TR-2008-002.pdf PDF",
  category = "Testing",
  csetags = "mernst,mernst-Testing,plse",
  summary =
   "A ``theory'' is a claim about one or more objects --- an executable predicate
    that generalizes over a (possibly infinite) set of tests.  Theories serve as
    a type of specification that can complement or supersede individual tests.",
}



@TechReport{ArtziKDTDPE2008:TR,
  author = 	 "Shay Artzi and Adam Kie{\.z}un and Julian Dolby and Frank Tip and Danny Dig and Amit Paradkar and Michael D. Ernst",
  authorASCII = 	 "Shay Artzi and Adam Kiezun and Julian Dolby and Frank Tip and Danny Dig and Amit Paradkar and Michael D. Ernst",
  title = 	 "Finding bugs in dynamic web applications",
  institution =  MITCSAIL,
  year = 	 2008,
  OPTkey = 	 "",
  OPTtype = 	 "",
  number = 	 "MIT-CSAIL-TR-2008-006",
  address = 	 MITaddr,
  month = 	 feb # "~6,",
  OPTnote = 	 "",
  OPTannote = 	 "",
  abstract =
   "Web script crashes and malformed dynamically-generated web pages are common
    errors, and they seriously impact usability of web applications. Current
    tools for web-page validation cannot handle the dynamically-generated pages
    that are ubiquitous on today's Internet. In this work, we apply a dynamic
    test generation technique, based on combined concrete and symbolic
    execution, to the domain of dynamic web applications. The technique
    generates tests automatically and minimizes the bug-inducing inputs to
    reduce duplication and to make the bug reports small and easy to understand
    and fix. We implemented the technique in Apollo, an automated tool that
    found dozens of bugs in real PHP applications.  Apollo generates test
    inputs for the web application, monitors the application for crashes, and
    validates that the output conforms to the HTML specification. This paper
    presents Apollo's algorithms and implementation, and an experimental
    evaluation that revealed a total of 214 bugs in 4 open-source PHP web
    applications.",
  basefilename = "web-apps-tr006",
  OPTdownloads = "",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/web-apps-tr006.pdf PDF",
  supersededby = "ArtziKDTDPE2008",
  category = "Testing",
  OMITcsetagsBECAUSESUPERSEDED = "mernst,mernst-Testing,plse",
  summary =
   "This paper extends dynamic test generation, based on interleaved
    testing and symbolic execution, to the new domain of web applications,
    and finds 214 bugs in 4 PHP web applications.",
}


@TechReport{ArtziKDTDPE2008:RC24528,
  author = 	 "Shay Artzi and Adam Kie{\.z}un and Julian Dolby and Frank Tip and Danny Dig and Amit Paradkar and Michael D. Ernst",
  authorASCII = 	 "Shay Artzi and Adam Kiezun and Julian Dolby and Frank Tip and Danny Dig and Amit Paradkar and Michael D. Ernst",
  title = 	 "Finding bugs in dynamic web applications",
  institution =  IBMTJWatson,
  year = 	 2008,
  number = 	 "RC24528",
  address = 	 IBMHawthorne,
  month = 	 apr # "~2,",
  basefilename = "web-apps-rc24528",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/web-apps-rc24528.pdf PDF",
  supersededby = "ArtziKDTDPE2008",
  category = "Testing",
}



@InProceedings{McCamantE2008,
  author = 	 "Stephen McCamant and Michael D. Ernst",
  title = 	 "Quantitative information flow as network flow capacity",
  crossref =     "PLDI2008",
  pages = 	 "193--205",
  OPTnote = 	 "",
  OPTannote = 	 "",
  abstract =
   "We present a new technique for determining how much information about
    a program's secret inputs is revealed by its public outputs.  In
    contrast to previous techniques based on reachability from secret
    inputs (tainting), it achieves a more precise quantitative result by
    computing a maximum flow of information between the inputs and
    outputs.  The technique uses static control-flow regions to soundly
    account for implicit flows via branches and pointer operations, but
    operates dynamically by observing one or more program executions and
    giving numeric flow bounds specific to them (e.g., ``17 bits'').  The
    maximum flow in a network also gives a minimum cut (a set of edges
    that separate the secret input from the output), which can be used to
    efficiently check that the same policy is satisfied on future
    executions.  We performed case studies on 5 real C, C++, and Objective
    C programs, 3 of which had more than 250K lines of code.  The tool
    checked multiple security policies, including one that was violated by
    a previously unknown bug.",
  basefilename = "secret-max-flow-pldi2008",
  downloads = "https://people.csail.mit.edu/smcc/projects/secret-flow/flowcheck.html Flowcheck implementation",
  downloadsnonlocal =
   "https://groups.csail.mit.edu/pag/pubs/secret-max-flow-pldi2008.pdf PDF",
  category = "Security",
  csetags = "mernst,mernst-Security,plse",
  summary =
   "To obtain a more precise measurement of the amount of secret information
    a program might reveal, we replace the usual technique of tainting
    (reachability from secret inputs) with a maximum-flow computation on
    a graph representation of execution with edge capacities. With
    appropriate optimizations, the technique scales to check realistic
    properties in several large C programs.",
}


@InProceedings{QuinonezTE2008,
  author = 	 "Jaime Quinonez and Matthew S. Tschantz and Michael D. Ernst",
  title = 	 "Inference of reference immutability",
  crossref =     "ECOOP2008",
  pages = 	 "616--641",
  abstract =
   "Javari is an extension of Java that supports reference
    immutability constraints.  Programmers write \texttt{readonly} type
    qualifiers and other constraints, and the Javari type-checker detects
    mutation errors (incorrect side effects) or verifies their absence.
    While case studies have demonstrated the practicality and value of
    Javari, a barrier to usability remains.
    A Javari program will not typecheck unless all the references
    in the APIs of libraries it uses are annotated with Javari
    type qualifiers.  Manually converting existing Java libraries to
    Javari is tedious and error-prone.
    \par
    We present an algorithm for inferring reference immutability
    in Javari.  The
    flow-insensitive and context-sensitive algorithm is sound and produces a set
    of qualifiers that typecheck in Javari.  The algorithm is
    precise in that it infers the most \texttt{readonly} qualifiers
    possible; adding any additional \texttt{readonly} qualifiers
    will cause the program to not typecheck.
    We have implemented the algorithm in a tool, Javarifier, that
    infers the Javari type qualifiers over a set of class files.
    \par
    Javarifier automatically converts Java libraries to Javari.  Additionally,
    Javarifier eases the task of converting legacy programs to Javari by
    inferring the mutability of every reference in a program.
    In case studies, Javarifier correctly inferred mutability over Java programs
    of up to 110 KLOC.",
  basefilename = "infer-refimmutability-ecoop2008",
  downloads =
   "https://groups.csail.mit.edu/pag/pubs/infer-refimmutability-quinonez-mengthesis.pdf Quinonez thesis;
    https://types.cs.washington.edu/javari/javarifier/ Javarifier implementation",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/infer-refimmutability-ecoop2008.pdf PDF",
  category = "Immutability (side effects)",
  csetags = "mernst,mernst-Immutability-(side-effects),plse",
  summary =
   "This paper presents a precise, scalable, novel algorithm for inference
    of reference immutability (as defined by the Javari language), and an
    experimental evaluation on substantial programs.",
  undergradCoauthor = 1,
}


@InProceedings{ArtziKE2008,
  author = 	 "Shay Artzi and Sunghun Kim and Michael D. Ernst",
  title = 	 "ReCrash: Making software failures reproducible by preserving object states",
  crossref =     "ECOOP2008",
  pages = 	 "542--565",
  abstract =
   "It is very hard to fix a software failure without being able to reproduce
    it.  However, reproducing a failure is often difficult and time-consuming.
    This paper proposes a novel technique, ReCrash, that generates multiple
    unit tests that reproduce a given program failure.  During every execution
    of the target program, ReCrash stores partial copies of method arguments in
    memory.  If the program fails (e.g., crashes), ReCrash uses the saved
    information to create unit tests reproducing the failure.
    \par
    We present ReCrashJ, an implementation of ReCrash for Java.  ReCrashJ
    reproduced real crashes from Javac, SVNKit, Eclipsec, and BST\@.  ReCrashJ
    is efficient, incurring 13\%--64\% performance overhead.  If this overhead
    is unacceptable, then ReCrashJ has another mode that has negligible
    overhead until a crash occurs and 0\%--1.7\% overhead until the crash
    occurs for a second time, at which point the test cases are generated.",
  basefilename = "reproduce-failures-ecoop2008",
  downloads = "https://groups.csail.mit.edu/pag/ReCrash/ ReCrash implementation",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/reproduce-failures-ecoop2008.pdf PDF",
  category = "Testing",
  csetags = "mernst,mernst-Testing,plse",
  summary =
   "ReCrash is a lightweight technique that monitors a program for failures such
    as crashes.  When a failure occurs in the field, ReCrash creates multiple
    unit tests that reproduce it.  This eases debugging and fixing the errors.",
}


@InProceedings{Ernst2008,
  author = 	 "Michael D. Ernst",
  title = 	 "Building and using pluggable type systems with the {Checker Framework}",
  crossref =     "ECOOP2008",
  note =         "Tool demo",
  abstract =
   "A static type system helps programmers to detect and prevent errors.
    However, a language's built-in type system does not help to detect and
    prevent enough errors, because it cannot express certain important
    invariants.  A user-defined, or pluggable, type system enriches a
    language's built-in type system via type qualifiers.  Pluggable types
    permit more expressive compile-time checking, and they can guarantee
    the absence of additional errors.  Example type qualifiers include
    nonnull, readonly, interned, and tainted.
    \par
    Despite considerable interest in user-defined type qualifiers,
    previous frameworks have been too inexpressive, unscalable, or
    incompatible with existing languages or tools.  This has hindered the
    evaluation, understanding, and uptake of pluggable types.
    \par
    The Checker Framework supports adding pluggable type systems to the
    Java language in a backward-compatible way.  The Checker Framework is
    useful to two constituencies.  A type system designer can create a
    type-checker for a custom type system.  A programmer can use the
    type-checker to detect errors or verify their absence.
    \par
    The Checker Framework is expressive and flexible.  It builds in many
    features needed by type system designers and programmers, including:
    \begin{itemize}
    \item backward-compatible Java and classfile syntax for type qualifiers
    \item integration with javac and Eclipse
    \item three type inference tools to ease programmer annotation burden
    \item declarative and procedural syntax for writing type-checking rules
    \item flow-sensitive type qualifier inference
    \item polymorphism over types (Java generics)
    \item polymorphism over type qualifiers
    \item implicit and default qualifiers
    \end{itemize}
    \par
    Experience indicates that the Checker Framework is useful to
    programmers and type system designers.  For programmers, type-checkers
    built using the Checker Framework have processed over 600K lines of
    code, finding real errors in every program.  For type system
    designers, the checkers are concise, even for robust implementations
    of sophisticated type systems, and the simplest type systems require
    writing no code at all.  The Checker Framework is being used by
    researchers around the world to perform realistic evaluation of type
    systems.  It has yielded new insight into existing type systems and
    has enabled the creation and evaluation of new ones.
    \par
    This demonstration will illustrate the power of the Checker Framework,
    both for programmers and for type system designers, and will prepare
    you to begin using it yourself.
    \par
    The Checker Framework is freely available at
      https://groups.csail.mit.edu/pag/jsr308/ .
    The distribution includes source code, binaries, extensive
    documentation, and example type-checkers.",
  usesDaikonAsTestSubject = 1,
  supersededby = "PapiACPE2008 A tool demonstration",
}

@InProceedings{Ernst2018,
  author = 	 "Michael D. Ernst",
  title = 	 "Pluggable type systems reconsidered: {ISSTA} 2018 {Impact Paper Award} for ``{Practical} Pluggable Types for {Java}''",
  crossref =  "ISSTA2018",
  note = 	 "keynote talk",
  omitfromcv = "*",
}

@InProceedings{ArtziKDTDPE2008,
  author = 	 "Shay Artzi and Adam Kie{\.z}un and Julian Dolby and Frank Tip and Danny Dig and Amit Paradkar and Michael D. Ernst",
  authorASCII = 	 "Shay Artzi and Adam Kiezun and Julian Dolby and Frank Tip and Danny Dig and Amit Paradkar and Michael D. Ernst",
  title = 	 "Finding bugs in dynamic web applications",
  crossref =     "ISSTA2008",
  pages = 	 "261--272",
  abstract =
   "Web script crashes and malformed dynamically-generated Web pages are common
    errors, and they seriously impact usability of Web applications.  Current
    tools for Web-page validation cannot handle the dynamically-generated pages
    that are ubiquitous on today's Internet.  In this work, we apply a dynamic
    test generation technique, based on combined concrete and symbolic
    execution, to the domain of dynamic Web applications. The technique
    generates tests automatically, uses the tests to detect failures, and
    minimizes the conditions on the inputs exposing each failure, so that the
    resulting bug reports are small and useful in finding and fixing the
    underlying faults.  Our tool Apollo implements the technique for PHP\@.
    Apollo generates test inputs for the Web application, monitors the
    application for crashes, and validates that the output conforms to the HTML
    specification.  This paper presents Apollo's algorithms and implementation,
    and an experimental evaluation that revealed 214 faults in 4 PHP Web
    applications.",
  basefilename = "bugs-webapps-issta2008",
  NOdownloads = "IBM proprietary tool",
  supersededby = "ArtziKDTDPE2010",
  downloadsnonlocal =
    "https://homes.cs.washington.edu/~mernst/pubs/bugs-webapps-issta2008.pdf PDF",
  category = "Test generation",
  OMITcsetagsBECAUSESUPERSEDED = "mernst,mernst-Testing,plse",
  summary =
   "This paper extends dynamic test generation, based on interleaved
    testing and symbolic execution, to the new domain of web applications,
    and finds 214 bugs in 4 PHP web applications.",
}


@InProceedings{PapiACPE2008,
  author = 	 "Matthew M. Papi and Mahmood Ali and Telmo Luis {Correa~Jr.} and Jeff H. Perkins and Michael D. Ernst",
  title = 	 "Practical pluggable types for {Java}",
  crossref =     "ISSTA2008",
  pages = 	 "201--212",
  doi = {10.1145/1390630.1390656},
  abstract =
   "This paper introduces the Checker Framework, which supports adding
    pluggable type systems to the Java language in a backward-compatible way.
    A type system designer defines type qualifiers and their semantics, and a
    compiler plug-in enforces the semantics.  Programmers can write the type
    qualifiers in their programs and use the plug-in to detect or prevent
    errors.  The Checker Framework is useful both to programmers who wish to
    write error-free code, and to type system designers who wish to evaluate
    and deploy their type systems.
    \par
    The Checker Framework includes new Java syntax for expressing type
    qualifiers; declarative and procedural mechanisms for writing
    type-checking rules; and support for flow-sensitive local type qualifier
    inference and for polymorphism over types and qualifiers.  The Checker
    Framework is well-integrated with the Java language and toolset.
    \par
    We have evaluated the Checker Framework by writing 5 checkers and running
    them on over 600K lines of existing code.  The checkers found real
    errors, then confirmed the absence of further errors in the fixed code.
    The case studies also shed light on the type systems themselves.",
  usesDaikonAsTestSubject = 1,
  basefilename = "pluggable-checkers-issta2008",
  downloads =
   "https://homes.cs.washington.edu/~mernst/pubs/pluggable-types-issta2008-slides.pdf talk slides (PDF);
    https://homes.cs.washington.edu/~mernst/pubs/pluggable-types-demo-slides.pdf demo slides (PDF);
    https://homes.cs.washington.edu/~mernst/pubs/pluggable-checkers-retrospective-issta2018-slides.pdf ISSTA 2018 retrospective slides (PDF);
    https://docs.google.com/presentation/d/1-DRyBQq-Afmu0nZnb7BK2vd95Nmr13O5xv3fNc0iBok/edit ISSTA 2018 retrospective slides (Google Slides);
    https://groups.csail.mit.edu/pag/pubs/pluggable-checkers-papi-mengthesis.pdf Papi thesis (PDF);
    https://checkerframework.org/ Checker Framework implementation",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/pluggable-checkers-issta2008.pdf PDF",
  category = "Programming language design",
  csetags = "mernst,mernst-Programming-language-design,plse",
  summary =
   "We have created a framework for pluggable type-checking in Java (including
    backward-compatible syntax).  Checkers built with the
    framework found real errors in existing software.",
  undergradCoauthor = 1,
}


@TechReport{DigME2008:TR053,
  author = 	 "Danny Dig and John Marrero and Michael D. Ernst",
  title = 	 "How do programs become more concurrent? A story of program transformations",
  institution =  MITCSAIL,
  year = 	 2008,
  number = 	 "MIT-CSAIL-TR-2008-053",
  address = 	 MITaddr,
  month = 	 sep # "~5,",
  abstract =
   "For several decades, programmers have relied on Moore's Law to improve the
    performance of their software applications. From now on, programmers need
    to program the multi-cores if they want to deliver efficient code. In the
    multi-core era, a major maintenance task will be to make sequential
    programs more concurrent. What are the most common transformations to
    retrofit concurrency into sequential programs?  We studied the source code
    of 5 open-source Java projects. We analyzed qualitatively and quantitatively
    the change patterns that developers have used in order to retrofit
    concurrency. We found that these transformations belong to four categories:
    transformations that improve the latency, the throughput, the scalability,
    or correctness of the applications. In addition, we report on our
    experience of parallelizing one of our own programs. Our findings can
    educate software developers on how to parallelize sequential programs, and
    can provide hints for tool vendors about what transformations are worth
    automating.",
  supersededby = "DigME2011",
  basefilename = "concurrent-history-tr053",
  downloadsnonlocal =
   "https://dspace.mit.edu/bitstream/handle/1721.1/42832/MIT-CSAIL-TR-2008-053.pdf PDF;
    https://dspace.mit.edu/bitstream/handle/1721.1/42832/MIT-CSAIL-TR-2008-053.ps PostScript",
  category = "Concurrency,Refactoring",
  OMITcsetagsBECAUSESUPERSEDED = "mernst,mernst-Refactoring,plse",
  summary =
   "This paper is a historical analysis of the transformations that
    programmers used to convert sequential programs into concurrent versions.",
  undergradCoauthor = 1,
}


@InProceedings{AliZPE2008,
  author = 	 "Mahmood Ali and Yoav Zibin and Matthew M. Papi and Michael D. Ernst",
  pseudoauthor = "Adam Kie{\.z}un",
  title = 	 "Enforcing reference and object immutability in {Java}",
  crossref =     "OOPSLACompanion2008",
  pages = 	 "725--726",
  supersededby = "ZibinPAAKE2007 A tool demonstration",
  undergradCoauthor = 1,
}


@InProceedings{PapiAE2008,
  author = 	 "Matthew M. Papi and Mahmood Ali and Michael D. Ernst",
  title = 	 "Compile-time type-checking for custom type qualifiers in {Java}",
  crossref =     "OOPSLACompanion2008",
  pages = 	 "723--724",
  usesDaikonAsTestSubject = 1,
  supersededby = "PapiACPE2008 A tool demonstration",
  undergradCoauthor = 1,
}


@TechReport{KiezunGJE2008,
  author = 	 "Adam Kie{\.z}un and Philip J. Guo and Karthick Jayaraman and Michael D. Ernst",
  authorASCII =	 "Adam Kiezun and Philip J. Guo and Karthick Jayaraman and Michael D. Ernst",
  title = 	 "Automatic creation of {SQL} injection and cross-site scripting attacks",
  institution =  MITCSAIL,
  year = 	 2008,
  number = 	 "MIT-CSAIL-TR-2008-054",
  address = 	 MITADDR,
  month = 	 sep # "~10,",
  abstract =
   "We present a technique for finding security vulnerabilities in Web
    applications.  SQL Injection (SQLI) and cross-site scripting (XSS) attacks
    are widespread forms of attack in which the attacker crafts the input to
    the application to access or modify user data and execute malicious code.
    In the most serious attacks (called second-order, or persistent, XSS), an
    attacker can corrupt a database so as to cause subsequent users to execute
    malicious code.
    \par
    This paper presents an automatic technique for creating inputs that expose
    SQLI and XSS vulnerabilities.  The technique generates sample inputs,
    symbolically tracks taints through execution (including through database
    accesses), and mutates the inputs to produce concrete exploits.  Ours is
    the first analysis of which we are aware that precisely addresses
    second-order XSS attacks.
    \par
    Our technique creates real attack vectors, has few false positives, incurs
    no runtime overhead for the deployed application, works without requiring
    modification of application code, and handles dynamic programming-language
    constructs.  We implemented the technique for PHP, in a tool Ardilla.  We
    evaluated Ardilla on five PHP applications and found 68 previously unknown
    vulnerabilities (23 SQLI, 33 first-order XSS, and 12 second-order XSS).",
  basefilename = "create-attacks-tr054",
  downloads = "https://groups.csail.mit.edu/pag/ardilla/ Experimental data",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/create-attacks-tr054.pdf PDF",
  supersededby = "KiezunGJE2009",
  category = "Test generation,Security",
  OMITcsetagsBECAUSESUPERSEDED = "mernst,mernst-Security,plse",
  summary =
   "By generating inputs that cause the program to execute particular
    statements, then modifying those inputs into attack vectors, it is
    possible to prove the presence of real, exploitable security vulnerabilities
    in PHP programs.",
}


@TechReport{DigME2008:TR057,
  author = 	 "Danny Dig and John Marrero and Michael D. Ernst",
  title = 	 "Refactoring sequential {Java} code for concurrency via concurrent libraries",
  institution =  MITCSAIL,
  year = 	 2008,
  number = 	 "MIT-CSAIL-TR-2008-057",
  address = 	 MITaddr,
  month = 	 sep # "~30,",
  abstract =
   "Parallelizing existing sequential programs to run efficiently on multicores
    is hard.  The Java 5 package \texttt{java.util.concurrent} (\texttt{j.u.c.})
    supports writing concurrent programs: much of the complexity of writing
    threads-safe and scalable programs is hidden in the library. To use this
    package, programmers still need to reengineer existing code. This is
    \emph{tedious} because it requires changing many lines of code, is
    \emph{error-prone} because programmers can use the wrong APIs, and is
    \emph{omission-prone} because programmers can miss opportunities to use the
    enhanced APIs.
    \par
    This paper presents our tool, Concurrencer, which enables programmers
    to refactor sequential code into parallel code that uses \texttt{j.u.c.}
    concurrent utilities. Concurrencer does not require any program
    annotations, although the transformations are very involved: they span
    multiple program statements and use custom program analysis. A
    find-and-replace tool can not perform such transformations. Empirical
    evaluation shows that Concurrencer refactors code effectively:
    Concurrencer correctly identifies and applies transformations that some
    open-source developers overlooked, and the converted code exhibits good
    speedup.",
  basefilename = "concurrent-refactoring-tr057",
  downloads =
   "https://web.archive.org/web/20170709075029/https://refactoring.info/tools/Concurrencer/ Concurrencer implementation",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/concurrent-refactoring-tr057.pdf PDF;
    https://dspace.mit.edu/bitstream/handle/1721.1/42841/MIT-CSAIL-TR-2008-057.pdf PDF (DSpace)",
  supersededby = "DigME2009",
  category = "Concurrency,Refactoring",
  OMITcsetagsBECAUSESUPERSEDED = "mernst,mernst-Refactoring,plse",
  summary =
   "This paper presents a refactoring tool, Concurrencer, that transforms
    sequential code into parallel code that uses the java.util.concurrent
    libraries.",
  undergradCoauthor = 1,
}



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%% 2009
%%%

@TechReport{KiezunGGHE2009:TR,
  author = 	 "Adam Kie{\.z}un and Vijay Ganesh and Philip J. Guo and Pieter Hooimeijer and Michael D. Ernst",
  authorASCII =  "Adam Kiezun and Vijay Ganesh and Philip J. Guo and Pieter Hooimeijer and Michael D. Ernst",
  title = 	 "{HAMPI}: A solver for string constraints",
  institution =  MITCSAIL,
  year = 	 2009,
  OPTkey = 	 "",
  OPTtype = 	 "",
  number = 	 "MIT-CSAIL-TR-2009-004",
  address = 	 MITaddr,
  month = 	 feb # "~4,",
  OPTnote = 	 "",
  OPTannote = 	 "",
  abstract =
   "Many automatic testing, analysis, and verification techniques for
    programs can be effectively reduced to a constraint-generation phase
    followed by a constraint-solving phase. This separation of concerns
    often leads to more effective and maintainable tools. The increasing
    efficiency of off-the-shelf constraint solvers makes this approach
    even more compelling. However, there are few, if any, effective and
    sufficiently expressive off-the-shelf solvers for string constraints
    generated by analysis techniques for string-manipulating programs.
    \par
    We designed and implemented HAMPI, a solver for string constraints
    over bounded string variables.  HAMPI constraints express membership
    in regular languages and bounded context-free languages.  HAMPI constraints
    may contain context-free-language definitions, regular-language
    definitions and operations, and the membership predicate.  Given a set
    of constraints, HAMPI outputs a string that satisfies all the
    constraints, or reports that the constraints are unsatisfiable.
    \par
    HAMPI is expressive and efficient, and can be successfully applied to
    testing and analysis of real programs.  Our experiments use HAMPI
    in: static and dynamic analyses for finding SQL injection vulnerabilities
    in Web applications; automated bug finding in~C
    programs using systematic testing; and compare HAMPI with another
    string solver.  HAMPI's source code,
    documentation, and the experimental data are available at
    \url{https://people.csail.mit.edu/akiezun/hampi/}.",
  basefilename = "string-solver-tr004",
  downloads =
   "https://people.csail.mit.edu/akiezun/hampi/ HAMPI implementation",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/string-solver-tr004.pdf PDF",
  supersededby = "KiezunGGHE2009",
  category = "Static analysis",
  OMITcsetagsBECAUSESUPERSEDED = "mernst,mernst-Static-analysis,plse",
  summary =
   "This paper describes an efficient and expressive solver (that is, a
    decision procedure) for string constraints such as language membership.
    Such a solver is useful when analyzing programs that manipulate strings.",
}



@Article{ArtziQKE2009,
  author = 	 "Shay Artzi and Jaime Quinonez and Adam Kie{\.z}un and Michael D. Ernst",
  pseudoauthor = "David Glasser",
  title = 	 "Parameter reference immutability: Formal definition, inference tool, and comparison",
  journal = 	 JASE,
  year = 	 2009,
  volume = 	 "16",
  number = 	 "1",
  pages = 	 "145--192",
  month = 	 mar,
  abstract =
   "Knowing which method parameters may be mutated during a method's
    execution is useful for many software engineering tasks.
    A parameter reference is \emph{immutable} if it cannot be used to modify the
     state of its referent object during the method's execution.
    We formally define this notion, in a core object-oriented language.
    Having the formal definition enables determining correctness and accuracy
    of tools approximating this definition and unbiased comparison of analyses
    and tools that approximate similar definitions.
    \par
    We present Pidasa, a tool for classifying parameter reference immutability.
    Pidasa combines several
    lightweight, scalable analyses in stages, with each stage
    refining the overall result.  The resulting analysis is scalable and
    combines the strengths of its component analyses.  As one of the
    component analyses, we present a novel dynamic mutability analysis
    and show how its results can be improved by random input generation.
    Experimental results on programs of up to~185 kLOC show that,
    compared to previous approaches, Pidasa increases both run-time performance
    and overall accuracy of immutability inference.",
  basefilename = "mutability-jase2009",
  downloads =
    "https://homes.cs.washington.edu/~mernst/pubs/mutability-ase2007-slides.pdf slides (PDF);
     https://homes.cs.washington.edu/~mernst/pubs/mutability-ase2007-slides.pptx slides (PowerPoint)",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/mutability-jase2009.pdf PDF",
  category = "Immutability (side effects)",
  csetags = "mernst,mernst-Immutability-(side-effects),plse",
  summary =
    "This paper defines reference immutability formally and precisely.  The
     paper gives new algorithms for inferring immutability that are more
     scalable and precise than previous approaches.  The paper compares our
     algorithms, previous algorithms, and the formal definition.",
  undergradCoauthor = 1,
}



@TechReport{ArtziKDTDPE2009,
  author = 	 "Shay Artzi and Adam Kie{\.z}un and Julian Dolby and Frank Tip and Danny Dig and Amit Paradkar and Michael D. Ernst",
  authorASCII = 	 "Shay Artzi and Adam Kiezun and Julian Dolby and Frank Tip and Danny Dig and Amit Paradkar and Michael D. Ernst",
  title = 	 "Finding bugs in web applications using dynamic test generation and explicit state model checking",
  institution =  MITCSAIL,
  year = 	 2009,
  number = 	 "MIT-CSAIL-TR-2009-010",
  address = 	 MITaddr,
  month = 	 mar # "~26,",
  abstract =
   "Web script crashes and malformed dynamically-generated web pages are
   common errors, and they seriously impact the usability of web
   applications. Current tools for web-page validation cannot handle the
   dynamically generated pages that are ubiquitous on today's Internet. We
   present a dynamic test generation technique for the domain of dynamic
   web applications. The technique utilizes both combined concrete and
   symbolic execution and explicit-state model checking. The technique
   generates tests automatically, runs the tests capturing logical
   constraints on inputs, and minimizes the conditions on the inputs to
   failing tests, so that the resulting bug reports are small and useful in
   finding and fixing the underlying faults.
   \par
   Our tool Apollo implements the technique for the PHP programming
   language. Apollo generates test inputs for a web application, monitors
   the application for crashes, and validates that the output conforms to
   the HTML specification. This paper presents Apollo's algorithms and
   implementation, and an experimental evaluation that revealed 302 faults
   in 6 PHP web applications.",
  basefilename = "bugs-webapps-tr2009",
  downloadsnonlocal =
    "https://homes.cs.washington.edu/~mernst/pubs/bugs-webapps-tr2009.pdf PDF",
  supersededby = "ArtziKDTDPE2010",
  category = "Test generation",
  OMITcsetagsBECAUSESUPERSEDED = "mernst,mernst-Testing,plse",
  summary =
   "This paper extends dynamic test generation, based on interleaved
    testing and symbolic execution, to the new domain of web applications,
    and finds 302 bugs in 6 PHP web applications.",
}


@InProceedings{DigME2009,
  author = 	 "Danny Dig and John Marrero and Michael D. Ernst",
  title = 	 "Refactoring sequential {Java} code for concurrency via concurrent libraries",
  crossref =     "ICSE2009",
  pages = 	 "397--407",
  abstract =
   "Parallelizing existing sequential programs to run efficiently on multicores
    is hard.  The Java 5 package \texttt{java.util.concurrent} (\texttt{j.u.c.})\
    supports writing concurrent programs: much of the complexity of writing
    thread-safe and scalable programs is hidden in the library. To use this
    package, programmers still need to reengineer existing code. This is
    \emph{tedious} because it requires changing many lines of code, is
    \emph{error-prone} because programmers can use the wrong APIs, and is
    \emph{omission-prone} because programmers can miss opportunities to use the
    enhanced APIs.
    \par
    This paper presents our tool, Concurrencer, that enables programmers to
    refactor sequential code into parallel code that uses three \texttt{j.u.c.}\
    concurrent utilities. Concurrencer does not require any program
    annotations. Its transformations span multiple, non-adjacent, program
    statements. A find-and-replace tool can not perform such transformations,
    which require program analysis. Empirical evaluation shows that
    Concurrencer refactors code effectively: Concurrencer correctly identifies
    and applies transformations that some open-source developers overlooked,
    and the converted code exhibits good speedup.",
  basefilename = "concurrent-refactoring-icse2009",
  downloads =
   "https://web.archive.org/web/20170709075029/https://refactoring.info/tools/Concurrencer/ Concurrencer implementation",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/concurrent-refactoring-icse2009.pdf PDF",
  category = "Concurrency,Refactoring",
  csetags = "mernst,mernst-Refactoring,plse",
  summary =
   "This paper presents a refactoring tool, Concurrencer, that transforms
    sequential code into parallel code that uses the java.util.concurrent
    libraries.",
  undergradCoauthor = 1,
}


@InProceedings{KiezunGJE2009,
  author = 	 "Adam Kie{\.z}un and Philip J. Guo and Karthick Jayaraman and Michael D. Ernst",
  authorASCII =	 "Adam Kiezun and Philip J. Guo and Karthick Jayaraman and Michael D. Ernst",
  title = 	 "Automatic creation of {SQL} injection and cross-site scripting attacks",
  crossref =     "ICSE2009",
  pages = 	 "199--209",
  abstract =
   "We present a technique for finding security vulnerabilities in Web
    applications.  SQL Injection (SQLI) and cross-site scripting (XSS) attacks
    are widespread forms of attack in which the attacker crafts the input to
    the application to access or modify user data and execute malicious code.
    In the most serious attacks (called second-order, or persistent, XSS), an
    attacker can corrupt a database so as to cause subsequent users to execute
    malicious code.
    \par
    This paper presents an automatic technique for creating inputs that expose
    SQLI and XSS vulnerabilities.  The technique generates sample inputs,
    symbolically tracks taints through execution (including through database
    accesses), and mutates the inputs to produce concrete exploits.  Ours is
    the first analysis of which we are aware that precisely addresses
    second-order XSS attacks.
    \par
    Our technique creates real attack vectors, has few false positives, incurs
    no runtime overhead for the deployed application, works without requiring
    modification of application code, and handles dynamic programming-language
    constructs.  We implemented the technique for PHP, in a tool Ardilla.  We
    evaluated Ardilla on five PHP applications and found 68 previously unknown
    vulnerabilities (23 SQLI, 33 first-order XSS, and 12 second-order XSS).",
  basefilename = "create-attacks-icse2009",
  downloads = "https://groups.csail.mit.edu/pag/ardilla/ Experimental data",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/create-attacks-icse2009.pdf PDF;
    https://homes.cs.washington.edu/~mernst/pubs/create-attacks-icse2009-slides.pdf slides (PDF)",
  category = "Test generation,Security",
  csetags = "mernst,mernst-Security,plse",
  summary =
   "By generating inputs that cause the program to execute particular
    statements, then modifying those inputs into attack vectors, it is
    possible to prove the presence of real, exploitable security vulnerabilities
    in PHP programs.",
}


@InProceedings{KiezunGGHE2009,
  author = 	 "Adam Kie{\.z}un and Vijay Ganesh and Philip J. Guo and Pieter Hooimeijer and Michael D. Ernst",
  authorASCII =  "Adam Kiezun and Vijay Ganesh and Philip J. Guo and Pieter Hooimeijer and Michael D. Ernst",
  title = 	 "{HAMPI}: A solver for string constraints",
  crossref =     "ISSTA2009",
  pages = 	 "105--116",
  abstract =
   "Many automatic testing, analysis, and verification techniques for
    programs can be effectively reduced to a constraint-generation phase
    followed by a constraint-solving phase. This separation of concerns
    often leads to more effective and maintainable tools. The increasing
    efficiency of off-the-shelf constraint solvers makes this approach
    even more compelling. However, there are few effective and
    sufficiently expressive off-the-shelf solvers for string constraints
    generated by analysis techniques for string-manipulating programs.
    \par
    We designed and implemented HAMPI, a solver for string constraints
    over fixed-size string variables.  HAMPI constraints express membership
    in regular languages and fixed-size context-free languages.  HAMPI constraints
    may contain context-free-language definitions, regular-language
    definitions and operations, and the membership predicate.  Given a set
    of constraints, HAMPI outputs a string that satisfies all the
    constraints, or reports that the constraints are unsatisfiable.
    \par
    HAMPI is expressive and efficient, and can be successfully applied to
    testing and analysis of real programs.  Our experiments use HAMPI
    in: static and dynamic analyses for finding SQL injection vulnerabilities
    in Web applications; automated bug finding in~C
    programs using systematic testing; and compare HAMPI with another
    string solver.  HAMPI's source code,
    documentation, and the experimental data are available at
    \url{https://people.csail.mit.edu/akiezun/hampi/}.",
  basefilename = "string-solver-issta2009",
  downloads =
   "https://people.csail.mit.edu/akiezun/hampi/ HAMPI implementation and experiments",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/string-solver-issta2009.pdf PDF",
  supersededby = "KiezunGAGHE2012",
  category = "Static analysis",
  csetags = "mernst,mernst-Static-analysis,plse",
  summary =
   "This paper describes an efficient and expressive solver (that is, a
    decision procedure) for string constraints such as language membership.
    Such a solver is useful when analyzing programs that manipulate strings.",
}


@TechReport{TipFKEBDS2009,
  author = 	 "Frank Tip and Robert M. Fuhrer and Adam Kiezun and Michael D. Ernst and Ittai Balaban and Bjorn De Sutter",
  title = 	 "Refactoring using type constraints",
  institution =  IBMTJWatson,
  year = 	 2009,
  number = 	 "RC24804",
  address = 	 IBMHawthorne,
  month = 	 jun # "~9,",
  abstract =
   "Type constraints express subtype relationships between the types of
    program expressions, for example those relationships that are required
    for type correctness.  Type constraints were originally proposed as a
    convenient framework for solving type checking and type inference
    problems.
    This paper shows how type constraints can be used as the basis for
    practical refactoring tools. In our approach, a set of type constraints is
    derived from a type-correct program $P$. The main insight behind our work
    is the fact that $P$ constitutes just one solution to this constraint
    system, and that alternative solutions may exist that correspond to
    refactored versions of $P$.
    We show how a number of refactorings for manipulating types and class
    hierarchies can be expressed naturally using type constraints. Several
    refactorings in the standard distribution of Eclipse are based on our
    work.",
  basefilename = "refactoring-type-constraints-rc24804",
  TODOdownloads = "*",
  supersededby = "TipFKEBDS2011",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/refactoring-type-constraints-rc24804.pdf PDF",
  category = "Refactoring",
  OMITcsetagsBECAUSESUPERSEDED = "mernst,mernst-Refactoring,plse",
  summary =
   "A program is one solution to the type constraints that are imposed by its
    interfaces and use of libraries.  Other solutions may be possible, and
    they represent legal refactiorings of the program."
}


@InProceedings{Ernst2009:SCAM,
  author = 	 "Michael D. Ernst",
  title = 	 "How analysis can hinder source code manipulation --- and what to do about it",
  crossref =     "SCAM2009",
  pages = 	 "xiii",
  abstract =
   "Source code analysis is a prerequisite to source code manipulation.  An
    understanding of what the code does --- that is, a model of its behavior --- is
    needed in order to propose or to verify a transformation, to enable
    subsequent analyses, and for other purposes.  The research community is
    justifiably proud of its many successful analysis techniques and
    applications.
    \par
    However, in some cases an analysis can hinder source code manipulation.
    Simple examples are a type system, style checker, or analysis that forbids,
    or cannot handle, certain code idioms.  Every programmer is familiar with
    adjusting coding style to the limitations of a language, framework, build
    system, etc.  Similar limitations apply to automated program manipulation.
    \par
    Related problems arise when analyzing legacy code.  A programmer may have
    chosen among multiple designs with similar qualities.  Later, when an
    analysis reveals a reason that one of them was preferable, the cost of
    reworking the program may be prohibitive, particularly if the
    transformation is not justified on correctness grounds.
    \par
    I will explore these and related problems in the context of type inference,
    type checking, and testing --- drawing connections and highlighting
    differences among them.  I will illustrate both the strengths of these
    activities and also some ways that they are less useful than they could be.
    I will suggest lifting some of their strictures, either temporarily and
    permanently, in an effort to give programmers the best of all worlds.",
  basefilename = "staticdynamic-scam2009",
  downloads =
   "https://github.com/mernst/ductilej implementation",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/staticdynamic-scam2009-slides.pdf Slides (PDF);
    https://homes.cs.washington.edu/~mernst/pubs/staticdynamic-scam2009-slides.pptx Slides (Powerpoint)",
  supersededby = "BayneCE2011",
  category = "Dynamic analysis",
  OMITcsetagsBECAUSESUPERSEDED = "mernst,mernst-Dynamic-analysis,plse",
  summary =
   "This talk proposes a way to obtain the rapid development of a
   dynamically-typed language, and the reliability and comprehensibility of
   a statically-typed language, via two views of the program during development.",
}


@InProceedings{PerkinsKLABCPSSSWZER2009,
  author = 	 "Jeff H. Perkins and Sunghun Kim and Sam Larsen and Saman Amarasinghe and Jonathan Bachrach and Michael Carbin and Carlos Pacheco and Frank Sherwood and Stelios Sidiroglou and Greg Sullivan and Weng-Fai Wong and Yoav Zibin and Michael D. Ernst and Martin Rinard",
  title = 	 "Automatically patching errors in deployed software",
  crossref =     "SOSP2009",
  pages = 	 "87--102",
  abstract =
   "We present ClearView, a system for automatically patching errors in
    deployed software. ClearView works on stripped Windows x86 binaries
    without any need for source code, debugging information, or other
    external information, and without human intervention.
    \par
    ClearView (1) observes normal executions to learn invariants that
    characterize the application's normal behavior, (2) uses error
    detectors to monitor the execution to detect failures, (3)
    identifies violations of learned invariants that occur during failed
    executions, (4) generates candidate repair patches that enforce
    selected invariants by changing the state or the flow of control to
    make the invariant true, and (5) observes the continued execution of
    patched applications to select the most successful patch.
    \par
    ClearView is designed to correct errors in software with high
    availability requirements. Aspects of ClearView that make it
    particularly appropriate for this context include its ability to
    generate patches without human intervention, to apply and remove
    patches in running applications without requiring restarts
    or otherwise perturbing the execution, and to identify and discard
    ineffective or damaging patches by evaluating the continued behavior
    of patched applications.
    \par
    In a Red Team exercise, ClearView survived attacks that exploit security
    vulnerabilities. A hostile external Red Team developed ten code-injection
    exploits and used these exploits to repeatedly attack an application
    protected by ClearView.  ClearView detected and blocked all of the
    attacks.  For seven of the ten exploits, ClearView automatically
    generated patches that corrected the error, enabling the application to
    survive the attacks and successfully process subsequent inputs.  The Red
    Team also attempted to make ClearView apply an undesirable patch, but
    ClearView's patch evaluation mechanism enabled ClearView to identify and
    discard both ineffective patches and damaging patches.",
  usesDaikon = 1,
  basefilename = "automatic-patching-sosp2009",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/automatic-patching-sosp2009.pdf PDF;
    https://homes.cs.washington.edu/~mernst/pubs/automatic-patching-sosp2009-slides.pdf Slides (PDF);
    https://homes.cs.washington.edu/~mernst/pubs/automatic-patching-sosp2009-slides.ppt Slides (PowerPoint)",
  category = "Program repair,Security",
  csetags = "mernst,mernst-Security,plse",
  summary =
   "The ClearView system automatically:  classifies executions as normal or
    attack; learns a model of the normal executions; generates patches that
    correct deviations from the model during an attack; evaluates the
    patches; and distributes the best one.  A hostile Red Team evaluation
    shows that ClearView is effective.",
}


@TechReport{PotaninLZE2009,
  author = 	 "Alex Potanin and Paley Li and Yoav Zibin and Michael D. Ernst",
  title = 	 "{Featherweight} {Ownership} and {Immutability} {Generic} {Java} ({FOIGJ})",
  institution =  "VUW School of Engineering and Computer Science",
  year = 	 2009,
  number = 	 "09-13",
  address = 	 "Wellington, New Zealand",
  month = 	 dec # "~14,",
  abstract =
   "This technical report presents the full set of formal rules and proofs
   that accompany our paper called ``Ownership and Immutability in Generic
   Java (OIGJ)''. Questions regarding this technical report should be
   directed to Alex Potanin ({\tt alex@ecs.vuw.ac.nz}).",
  basefilename = "ownership-immutability-tr0913",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/ownership-immutability-tr0913.pdf PDF",
  OTHERdownloadsnonlocal =
   "https://ecs.victoria.ac.nz/foswiki/pub/Main/TechnicalReportSeries/ECSTR09-13.pdf PDF",
  category = "Immutability (side effects),Ownership (encapsulation)",
  csetags = "mernst,mernst-Programming-language-design,plse",
  TOBEsupersededby = "Zibin2010",
  summary =
   "This paper prestents a formalism and proofs of a type system (OIGJ)
   that combines ownership with immutablity.  This report has since been
   superseded.",
}



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%% 2010
%%%


@TechReport{SpotoE2010:TR,
  author = 	 "Fausto Spoto and Michael D. Ernst",
  title = 	 "Inference of field initialization",
  institution =  UWCSEDept,
  year = 	 2010,
  number = 	 "UW-CSE-10-02-01",
  address = 	 UWCSEaddr,
  monthANDDAY = 	 feb # "~6,",
  month = 	 feb # "~6,",
  abstract =
   "A raw object is partially initialized, with only some of its fields
    set to legal values. A raw object may violate its object invariants,
    such as that a given field is non-\texttt{null}. Programs often need to
    manipulate partially-initialized objects, but they must do so with
    care. Furthermore, analyses must be aware of rawness. For instance,
    software verification cannot depend on object invariants for
    raw objects.
    \par
    We present a static analysis that infers a safe over-approximation
    of the program variables, fields, or array elements that, at runtime,
    might hold non-fully initialized objects. Our formalization
    is flow-sensitive and considers the exception flow in the analyzed
    programs. We have proved the analysis to be sound.
    \par
    We have also implemented our analysis, in a tool called Julia
    that computes both nullness and rawness information. We have
    evaluated Julia on over 50K lines of code. We have compared its
    output to manually-written nullness and rawness information, and
    to an independently-written type-checking tool that checks nullness
    and rawness. Julia's output is accurate and, we believe, useful
    both to programmers and to static analyses.",
  basefilename = "field-initialization-tr100201",
  downloadsnonlocal = "ftp://ftp.cs.washington.edu/tr/2010/02/UW-CSE-10-02-01.PDF PDF",
  supersededby = "SpotoE2011 a previous version with some additional details",
  category = "Static analysis",
  OMITcsetagsBECAUSESUPERSEDED = "mernst,mernst-Static-analysis,plse",
  summary =
   "This paper presents a flow-sensitive, exception-aware static analysis that
    infers what program variables might hold not-yet-fully-initialized objects.
    Such an object might violate its object invariants, until its
    initialization is complete.",
}


@TechReport{BrunHEN2010:TR,
  author = 	 "Yuriy Brun and Reid Holmes and Michael D. Ernst and David Notkin",
  title = 	 "Speculative identification of merge conflicts and non-conflicts",
  institution =  UWCSEDept,
  year = 	 2010,
  number = 	 "UW-CSE-10-03-01",
  address = 	 UWCSEaddr,
  month = 	 mar,
  abstract =
   "Most software is built by multiple people, and a version control
    system integrates evolving individual contributions into a whole.
    Every engineer makes decisions about when to incorporate other team
    members' changes, and when to share changes with other team members.
    Sometimes, an engineer performs these tasks too early, and in other
    cases performs them too late.  In this paper we address several
    questions to determine if there are enough situations in practice where
    an individual could benefit from explicit knowledge about the
    relationship between their view of the software with respect to other
    views of the software.  In particular, we speculate (in principle) at
    each moment in time about whether unrecognized conflicts with
    teammates exist and whether there are unnoticed opportunities for
    straightforward merging among teammates.
    \par
    To determine whether there are sufficient potential opportunities ---
    needed to justify the design, implementation, and evaluation of a
    speculative tool --- we analyze existing source code repositories.
    Across several open-source projects, we compute and report results
    including how long conflicts persist before they are resolved (a mean
    of 9.8 days) and how long opportunities for a non-conflicting textual
    merge persist (a mean of 11 days).  In addition, for one of the
    projects, we compare the persistence of textual conflicts
    vs.\ compilation conflicts vs.\ testing conflicts.  Our data show that
    there is ample opportunity to benefit from speculative version
    control, justifying a tool design and implementation effort.",
  basefilename = "speculative-merge-tr100301",
  downloadsnonlocal = "ftp://ftp.cs.washington.edu/tr/2010/03/UW-CSE-10-03-01.PDF PDF",
  supersededby = "BrunHEN2011",
  category = "Speculative analysis",
  OMITcsetagsBECAUSESUPERSEDED = "mernst,notkin,mernst-Software-engineering,plse",
  summary =
   "Are software engineers sometimes unaware that their work conflicts with
   that of their teammates?  Are they sometimes unaware that the work has
   no conflicts?  We investigate how often a tool could provide this
   information, which could help to avoid deviations or wasted work.",
}


@InProceedings{Ernst2010:TAP,
  author = 	 "Michael D. Ernst",
  title = 	 "How tests and proofs impede one another: The need for always-on static and dynamic feedback",
  crossref =     "TAP2010",
  pages = 	 "1--2",
  abstract =
   "Dynamic and static feedback provide complementary benefits, and neither one
    dominates the other.  Sometimes, sound global static checking is most
    useful.  At other times, running tests is most useful.  Unfortunately,
    current languages impose too rigid a model of the development process:
    they favor either static or dynamic tools, which prevents the programmer
    from freely using the other variety.  I propose a new approach, in which
    the developer always has access to immediate execution feedback, and always
    has access to sound static feedback.
    \par
    The aim is to permit developers to work the way they find most natural and
    effective, which will improve reliability and reduce cost.  Developers will
    create software that is more reliable than that created in an environment
    that favors dynamic analysis.  Developers will work faster than they can in
    an environment that favors static analysis.",
  basefilename = "staticdynamic-tap2010",
  downloads =
   "https://malaga2010.lcc.uma.es/tv/tools5.html Video;
    https://github.com/mernst/ductilej implementation",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/staticdynamic-tap2010.pdf extended abstract (PDF);
    https://homes.cs.washington.edu/~mernst/pubs/staticdynamic-tap2010-slides.pdf Slides (PDF);
    https://homes.cs.washington.edu/~mernst/pubs/staticdynamic-tap2010-slides.pptx Slides (Powerpoint)",
  supersededby = "BayneCE2011",
  category = "Dynamic analysis",
  OMITcsetagsBECAUSESUPERSEDED = "mernst,mernst-Dynamic-analysis,plse",
  summary =
   "This talk proposes a way to obtain the rapid development of a
   dynamically-typed language, and the reliability and comprehensibility of
   a statically-typed language, via two views of the program during development.",
}


@Article{ArtziKDTDPE2010,
  author = 	 "Shay Artzi and Adam Kie{\.z}un and Julian Dolby and Frank Tip and Danny Dig and Amit Paradkar and Michael D. Ernst",
  authorASCII = 	 "Shay Artzi and Adam Kiezun and Julian Dolby and Frank Tip and Danny Dig and Amit Paradkar and Michael D. Ernst",
  title = 	 "Finding bugs in web applications using dynamic test generation and explicit state model checking",
  journal = 	 TSE,
  year = 	 2010,
  volume = 	 36,
  number = 	 4,
  pages = 	 "474--494",
  month = 	 jul # "/" # aug,
  abstract =
   "Web script crashes and malformed dynamically-generated web pages are common
    errors, and they seriously impact the usability of web applications.
    Current tools for web-page validation cannot handle the dynamically
    generated pages that are ubiquitous on today's Internet.  We present a
    dynamic test generation technique for the domain of dynamic web
    applications.  The technique utilizes both combined concrete and symbolic
    execution and explicit-state model checking.  The technique generates tests
    automatically, runs the tests capturing logical constraints on inputs, and
    minimizes the conditions on the inputs to failing tests, so that the
    resulting bug reports are small and useful in finding and fixing the
    underlying faults.
    \par
    Our tool Apollo implements the technique for the PHP programming language.
    Apollo generates test inputs for a web application, monitors the
    application for crashes, and validates that the output conforms to the HTML
    specification.  This paper presents Apollo's algorithms and implementation,
    and an experimental evaluation that revealed 673 faults in 6 PHP web
    applications.",
  basefilename = "bugs-webapps-tse2010",
  downloadsnonlocal =
    "https://homes.cs.washington.edu/~mernst/pubs/bugs-webapps-tse2010.pdf PDF",
  category = "Test generation",
  csetags = "mernst,mernst-Testing,plse",
  summary =
   "This paper extends dynamic test generation, based on combined
    concrete and symbolic execution, to the new domain of web applications,
    and finds 673 bugs in 6 PHP web applications.",
}


@InProceedings{BuHBE2010,
  author = 	 "Yingyi Bu and Bill Howe and Magdalena Balazinska and Michael D. Ernst",
  title = 	 "{HaLoop}: Efficient Iterative Data Processing on Large Clusters",
  crossref =     "VLDB2010",
  pages = 	 "285--296",
  abstract =
   "The growing demand for large-scale data mining and data analysis
    applications has led both industry and academia to design new types of
    highly scalable data-intensive computing platforms. MapReduce and Dryad
    are two popular platforms in which the dataflow takes the form of a
    directed acyclic graph of operators.  These platforms lack built-in
    support for iterative programs, which arise naturally in many applications
    including data mining, web ranking, graph analysis, model fitting, and so
    on.  This paper presents HaLoop, a modified version of the Hadoop
    MapReduce framework that is designed to serve these applications.  HaLoop
    not only extends MapReduce with programming support for iterative
    applications, it also dramatically improves their efficiency by making the
    task scheduler loop-aware and by adding various caching mechanisms.  We
    evaluated HaLoop on real queries and real datasets.  Compared with Hadoop,
    on average, HaLoop reduces query runtimes by 1.85, and shuffles only 4\%
    of the data between mappers and reducers.",
  basefilename = "haloop-vldb2010",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/haloop-vldb2010.pdf PDF",
  supersededby = "BuHBErnst2012",
  FUTUREcategory =  "Databases",
  category = "Miscellaneous",
  OMITcsetagsBECAUSESUPERSEDED = "ybu,billhowe,magda,mernst,mernst-Miscellaneous,plse",
  summary =
   "An iterative job may repeat similar work on each iteration.  This paper
    shows how to avoid repeating work in iterative MapReduce jobs,
    substantially improving performance.",
}


@InProceedings{SchneiderBCEB2010,
  author = 	 "Sigurd Schneider and Ivan Beschastnikh and Slava Chernyak and Michael D. Ernst and Yuriy Brun",
  title = 	 "Synoptic: Summarizing system logs with refinement",
  crossref =     "SLAML2010",
  NOpages =      "*",
  abstract =
   "Distributed systems are often difficult to debug and understand.  A
    typical way of gaining insight into system behavior is by inspecting
    execution logs. However, manual inspection of logs is an arduous
    process. To support this task we developed \emph{Synoptic}.
    Synoptic outputs a concise graph representation of logged events
    that captures temporal invariants mined from the log.
    \par
    We applied Synoptic to synthetic and real distributed system logs
    and found that it augmented a distributed system designer's
    understanding of system behavior with reasonable overhead for an
    offline analysis tool. In contrast to prior approaches, Synoptic
    uses a combination of refinement and coarsening to explore the space
    of representations. Additionally, it infers temporal event
    invariants to capture distributed system semantics. These invariants
    drive the exploration process and are satisfied by the final
    representation.",
  basefilename = "synoptic-slaml2010",
  downloads =
   "https://github.com/ModelInference/synoptic implementation",
  OPTdownloadsnonlocal = "",
  supersededby = "BeschastnikhBSSE2011",
  category = "Distributed systems,Specification inference",
  csetags = "ivanb,mernst,brun,mernst-Dynamic-analysis,proj-synoptic,plse",
  summary =
   "Synoptic produces a small graph that summarizes a distributed system log.
    Synoptic starts from the smallest possible graph and iteratively expands,
    and it mines then enforces invariants from the original logs.",
  undergradCoauthor = 1,
}


@InProceedings{ZibinPLAE2010,
  author = 	 "Yoav Zibin and Alex Potanin and Paley Li and Mahmood Ali and Michael D. Ernst",
  title = 	 "Ownership and immutability in generic {Java}",
  crossref =     "OOPSLA2010",
  pages = 	 "598--617",
  abstract =
   "The Java language lacks the important notions of \emph{ownership} (an
    object owns its representation to prevent unwanted aliasing) and
    \emph{immutability} (the division into mutable, immutable, and readonly
    data and references).  Programmers are prone to design errors, such as
    representation exposure or violation of immutability contracts.  This paper
    presents \emph{Ownership Immutability Generic Java} (OIGJ), a
    backward-compatible purely-static language extension supporting ownership
    and immutability.  We formally defined a core calculus for OIGJ, based on
    Featherweight Java, and proved it sound.  We also implemented OIGJ and
    performed case studies on 33,000 lines of code.
    \par
    Creation of immutable cyclic structures requires a ``\emph{cooking phase}''
    in which the structure is mutated but the outside world cannot observe this
    mutation.  OIGJ uses \emph{ownership} information to facilitate creation of
    \emph{immutable} cyclic structures, by safely prolonging the cooking phase
    even after the constructor finishes.
    \par
    OIGJ is easy for a programmer to use, and it is easy to implement
    (flow-insensitive, adding only 14 rules to those of Java).  Yet, OIGJ is
    more expressive than previous ownership languages, in the sense that it can
    type-check more good code.  OIGJ can express the factory and visitor
    patterns, and OIGJ can type-check Sun's \texttt{java.util} collections
    (except for the \texttt{clone} method) without refactoring and with only a
    small number of annotations.  Previous work required major refactoring of
    existing code in order to fit its ownership restrictions.  Forcing
    refactoring of well-designed code is undesirable because it costs
    programmer effort, degrades the design, and hinders adoption in the
    mainstream community.",
  basefilename = "ownership-immutability-oopsla2010",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/ownership-immutability-oopsla2010.pdf PDF",
  downloads =
   "https://ecs.wgtn.ac.nz/foswiki/pub/Main/TechnicalReportSeries/ECSTR10-16.pdf TR with proofs",
  TODOdownloads = ";
    https://checkerframework.org/manual#igj-checker implementation",
  category = "Immutability (side effects),Ownership (encapsulation)",
  csetags = "mernst,mernst-Programming-language-design,plse",
  summary =
   "This paper shows how to combine ownership and immutability, producing a
   result that is more expressive and safe than previous attempts.  The paper
   includes both a proof of soundness and an implementation with case studies.",
  undergradCoauthor = 1,
}


@InProceedings{BrunHEN2010:FOSER,
  author = 	 "Yuriy Brun and Reid Holmes and Michael D. Ernst and David Notkin",
  title = 	 "Speculative analysis:  Exploring future development states of software",
  crossref =     "FOSER2010",
  pages = 	 "59--64",
  abstract =
   "Most software tools and environments help developers analyze the present
    and past development states of their software systems.  Few approaches
    have investigated the potential consequences of \emph{future} actions the
    developers may perform. The commoditization of hardware, multi-core
    architectures, and cloud computing provide new potential for delivering
    apparently-instantaneous feedback to developers, informing them of the
    effects of changes that they may be considering to the software.
    \par
    For example, modern IDEs often provide ``quick fix'' suggestions for
    resolving compilation errors.  Developers must scan this list and select
    the option they think will resolve the problem.  Instead, we propose that
    the IDE should speculatively perform each of the suggestions in the
    background and provide information that helps developers select the best
    option for the given context. We believe the feedback enabled by
    speculative operations can improve developer productivity and software
    quality.",
  basefilename = "speculation-foser2010",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/speculation-foser2010.pdf PDF;
    https://homes.cs.washington.edu/~mernst/pubs/speculation-foser2010-slides.pdf slides (PDF)",
  downloads =
   "https://github.com/brunyuriy/quick-fix-scout Quick Fix Scout implementation",
  OPTsupersededby = "",
  category = "Speculative analysis",
  csetags = "brun,mernst,notkin,mernst-Software-engineering,plse",
  summary =
   "This paper proposes that tools should analyze program versions that do not
    exist yet but that a developer might create.  This may help the developer
    decide in advance whether or not to create that particular version.",
}

@InProceedings{SchillerE2010,
  author = 	 "Todd W. Schiller and Michael D. Ernst",
  title = 	 "Rethinking the economics of software engineering",
  crossref =     "FOSER2010",
  pages = 	 "325--330",
  abstract =
   "Reliance on skilled developers reduces the return on investment for
    important software engineering tasks such as establishing program
    correctness.  This position paper introduces \emph{adaptive
      semi-automated} (ASA) tools as a means to enable less-skilled workers
    to perform aspects of software engineering tasks. In an ASA tool, a task
    is decomposed and the computationally difficult subtasks are performed by
    less-skilled workers using an adaptive user interface, reducing or
    eliminating the skilled developer's effort.
    \par
    We describe strategies for decomposing a software engineering task and
    propose design principles to maximize the cost effectiveness of ASA tools
    in the presence of imperfect decomposition.  Though the approach can be
    applied to many different types of tasks, this paper focuses on and
    provides examples for the software correctness tasks of test generation,
    program verification, and program synthesis. Additionally, we address the
    auxiliary challenges of latency, intellectual property risk, and worker
    error.",
  basefilename = "economics-foser2010",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/economics-foser2010.pdf PDF",
  OPTsupersededby = "",
  category = "Software engineering",
  csetags = "tws,mernst,mernst-Software-engineering,plse,proj-veriweb",
  summary =
   "We propose to build tools that permit less-skilled workers to perform
    certain tasks currently done by developers.  This frees developers to do
    tasks that only they can do, and overall makes software less expensive.",
}




%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%% 2011
%%%


@TechReport{LiE2011,
  author = 	 "Jingyue Li and Michael D. Ernst",
  title = 	 "{CBCD}: {Cloned} {Buggy} {Code} {Detector}",
  institution =  UWCSEDept,
  year = 	 2011,
  number = 	 "UW-CSE-11-05-02",
  address = 	 UWCSEaddr,
  month = 	 may # "~2,",
  note = 	 "Revised " # oct # " 2011",
  abstract =
   "Developers often copy, or clone, code in order to reuse or modify
    functionality.  When they do so, they also clone any bugs in the original
    code.  Or, different developers may independently make the same mistake.
    As one example of a bug, multiple products in a product line may use a
    component in a similar wrong way.  This paper makes two contributions.
    First, it presents an empirical study of cloned buggy code.  In a large
    industrial product line, about 4\% of the bugs are duplicated across more
    than one product or file.  In three open source projects (the Linux kernel,
    the Git version control system, and the PostgreSQL database) we found 282,
    33, and 33 duplicated bugs, respectively.  Second, this paper presents a
    tool, CBCD, that searches for code that is semantically identical to given
    buggy code.  CBCD tests graph isomorphism over the Program Dependency Graph
    (PDG) representation and uses four optimizations.  We evaluated CBCD by
    searching for known clones of buggy code segments in the three projects and
    compared the results with text-based, token-based, and AST-based code clone
    detectors, namely Simian, CCFinder, and CloneDr.  The results of the
    evaluation show that CBCD is applicable for its principal use: it is fast
    when searching for possible clones of the buggy code in a large system and
    it is more precise than the other code clone detectors.",
  supersededby = "LiE2012",
  basefilename = "buggy-clones-tr110502",
  category = "Defect prediction",
  OMITcsetagsBECAUSESUPERSEDED = "mernst,mernst-Software-engineering,plse",
  summary =
   "When programmers clone code, they also clone bugs.  This paper presents a
    technique to find clones of just-fixed bugs, so the clones can also be fixed.",
}


@Article{TipFKEBDS2011,
  author = 	 "Tip, Frank and Fuhrer, Robert M. and Kie{\.z}un, Adam and Michael D. Ernst and Balaban, Ittai and Sutter, Bjorn De",
  title = 	 "Refactoring using type constraints",
  journal = 	 TOPLAS,
  year = 	 2011,
  volume = 	 33,
  number = 	 3,
  pages = 	 "9:1--9:47",
  month = 	 may,
  abstract =
   "Type constraints express subtype relationships between the types of program
    expressions, for example, those relationships that are required for type
    correctness. Type constraints were originally proposed as a convenient
    framework for solving type checking and type inference problems. This paper
    shows how type constraints can be used as the basis for practical
    refactoring tools. In our approach, a set of type constraints is derived
    from a type-correct program P\@. The main insight behind our work is the
    fact that P constitutes just one solution to this constraint system, and
    that alternative solutions may exist that correspond to refactored versions
    of P\@. We show how a number of refactorings for manipulating types and
    class hierarchies can be expressed naturally using type
    constraints. Several refactorings in the standard distribution of Eclipse
    are based on our work.",
  basefilename = "refactoring-type-constraints-toplas2011",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/refactoring-type-constraints-toplas2011.pdf PDF",
  category = "Refactoring",
  csetags = "mernst,mernst-Refactoring,plse",
  summary =
   "A program is one solution to the type constraints that are imposed by its
    interfaces and use of libraries.  Other solutions may be possible, and
    they represent legal refactiorings of the program."
}


@InProceedings{DigME2011,
  author = 	 "Danny Dig and John Marrero and Michael D. Ernst",
  title = 	 "How do programs become more concurrent?  A story of program transformations",
  crossref =     "MSE2011",
  pages = 	 "43--50",
  abstract =
   "In the multi-core era, programmers need to resort to parallelism if they
    want to improve program performance. Thus, a major maintenance task will be
    to make sequential programs more concurrent. Must concurrency be designed
    into a program, or can it be retrofitted later? What are the most common
    transformations to retrofit concurrency into sequential programs? Are these
    transformations random, or do they belong to certain categories? How can we
    automate these transformations?
    \par
    To answer these questions we analyzed the source code of five open-source
    Java projects and looked at a total of 14 versions. We analyzed
    qualitatively and quantitatively the concurrency-related
    transformations. We found that these transformations belong to four
    categories: transformations that improve the responsiveness, the
    throughput, the scalability, or correctness of the applications. In 73.9\%
    of these transformations, concurrency was retrofitted on existing program
    elements. In 20.5\% of the transformations, concurrency was designed into
    new program elements. Our findings educate software developers on how to
    parallelize sequential programs, and provide hints for tool vendors about
    what transformations are worth automating.",
  basefilename = "concurrent-history-iwmse2011",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/concurrent-history-iwmse2011.pdf PDF",
  category = "Concurrency,Refactoring",
  csetags = "mernst,mernst-Refactoring,plse",
  summary =
   "This paper is a historical analysis of the transformations that
    programmers used to convert sequential programs into concurrent versions.",
  undergradCoauthor = 1,
}



@InProceedings{SpotoE2011,
  author = 	 "Fausto Spoto and Michael D. Ernst",
  title = 	 "Inference of field initialization",
  crossref =     "ICSE2011",
  pages = 	 "231--240",
  abstract =
   "A \emph{raw} object is partially initialized, with only some fields set to
    legal values.  It may violate its object invariants, such as that a given
    field is non-\texttt{null}.  Programs often manipulate partially-initialized
    objects, but they must do so with care.  Furthermore, analyses must be
    aware of field initialization.  For instance, proving the absence of
    null pointer dereferences or of division by zero, or proving that object
    invariants are satisfied, requires information about initialization.
    \par
    We present a static analysis that infers a safe over-approximation of the
    program variables, fields, and array elements that, at run time, might hold
    raw objects.  Our formalization is flow-sensitive and interprocedural, and
    it considers the exception flow in the analyzed program.  We have proved
    the analysis sound and implemented it in a tool called Julia that computes
    initialization and nullness information.  We have evaluated Julia on over
    160K lines of code.  We have compared its output to manually-written
    initialization and nullness information, and to an independently-written
    type-checking tool that checks initialization and nullness.  Julia's
    output is accurate and useful both to programmers and to static
    analyses.",
  usesDaikonAsTestSubject = 1,
  basefilename = "initialization-icse2011",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/initialization-icse2011.pdf PDF;
    https://homes.cs.washington.edu/~mernst/pubs/initialization-icse2011-slides.pdf slides (PDF)",
  downloads =
    "ftp://ftp.cs.washington.edu/tr/2010/02/UW-CSE-10-02-01.PDF earlier TR with additional details",
  OLDdownloads =
    "https://portal.juliasoft.com/ implementation;
     ftp://ftp.cs.washington.edu/tr/2010/02/UW-CSE-10-02-01.PDF earlier TR with additional details",
  OPTdownloadsnonlocal = "",
  category = "Static analysis",
  csetags = "mernst,mernst-Static-analysis,plse",
  summary =
   "This paper presents a flow-sensitive, exception-aware static analysis that
    infers what program variables might hold not-yet-fully-initialized objects.
    Such an object might violate its object invariants, until its
    initialization is complete.",
}


@InProceedings{BayneCE2011,
  author = 	 "Michael Bayne and Richard Cook and Michael D. Ernst",
  title = 	 "Always-available static and dynamic feedback",
  crossref =     "ICSE2011",
  pages = 	 "521--530",
  abstract =
   "Developers who write code in a statically typed language are denied the
    ability to obtain dynamic feedback by executing their code during periods
    when it fails the static type checker. They are further confined to the
    static typing discipline during times in the development process where it
    does not yield the highest productivity. If they opt instead to use a
    dynamic language, they forgo the many benefits of static typing,
    including machine-checked documentation, improved correctness and
    reliability, tool support (such as for refactoring), and better runtime
    performance.
    \par
    We present a novel approach to giving developers the benefits of both
    static and dynamic typing, throughout the development process, and
    without the burden of manually separating their program into statically-
    and dynamically-typed parts.  Our approach, which is intended for
    temporary use during the development process, relaxes the static type
    system and provides a semantics for many type-incorrect programs.  It
    defers type errors to run time, or suppresses them if they do not affect
    runtime semantics.
    \par
    We implemented our approach in a publicly available tool, DuctileJ, for
    the Java language. In case studies, DuctileJ conferred benefits both
    during prototyping and during the evolution of existing code.",
  basefilename = "ductile-icse2011",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/ductile-icse2011.pdf PDF;
    https://homes.cs.washington.edu/~mernst/pubs/ductile-icse2011-slides.pdf slides (PDF)",
  downloads =
    "https://github.com/mernst/ductilej DuctileJ implementation",
  category = "Programming language design",
  csetags = "mernst,mernst-Programming-language-design,plse",
  summary =
   "The DuctileJ language enables the rapid development and flexibility of a
    dynamically-typed language, and the reliability and comprehensibility of a
    statically-typed language, via two views of the program during development.",
}


@InProceedings{DietlDEMS2011,
  author = 	 "Werner Dietl and Stephanie Dietzel and Michael D. Ernst and K{\i}van{\c{c}} Mu{\c{s}}lu and Todd Schiller",
  authorASCII = 	 "Werner Dietl and Stephanie Dietzel and Michael D. Ernst and Kivanc Muslu and Todd Schiller",
  title = 	 "Building and using pluggable type-checkers",
  crossref =     "ICSE2011",
  pages = 	 "681--690",
  abstract =
   "This paper describes practical experience building and using pluggable
    type-checkers.  A pluggable type-checker refines (strengthens) the
    built-in type system of a programming language.  This permits programmers
    to detect and prevent, at compile time, defects that would otherwise have
    been manifested as run-time errors.  The prevented defects may be
    generally applicable to all programs, such as null pointer dereferences.
    Or, an application-specific pluggable type system may be designed for a
    single application.
    \par
    We built a series of pluggable type checkers using the Checker Framework,
    and evaluated them on 2 million lines of code, finding hundreds of bugs
    in the process.  We also observed 28 first-year computer science students
    use a checker to eliminate null pointer errors in their course projects.
    \par
    Along with describing the checkers and characterizing the bugs we found,
    we report the insights we had throughout the process.  Overall, we found
    that the type checkers were easy to write, easy for novices to
    productively use, and effective in finding real bugs and verifying
    program properties, even for widely tested and used open source projects.",
  basefilename = "pluggable-checkers-icse2011",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/pluggable-checkers-icse2011.pdf PDF;
    https://homes.cs.washington.edu/~mernst/pubs/pluggable-checkers-icse2011-slides.pdf slides (PDF)",
  downloads =
    "https://checkerframework.org/ implementation",
  usesDaikonAsTestSubject = 1,
  category = "Programming language design",
  csetags = "wmd,sdietzel,mernst,kinanc,tws,mernst-Programming-language-design,plse",
  summary =
   "This paper evaluates the ease of pluggable type-checking with the Checker
    Framework.  The type checkers were easy to write, easy for novices to
    use, and effective in finding hundreds of errors in case studies of 2
    million lines of code.",
  undergradCoauthor = 1,
}


@InProceedings{ZhangSBE2011,
  author = 	 "Sai Zhang and David Saff and Yingyi Bu and Michael D. Ernst",
  title = 	 "Combined static and dynamic automated test generation",
  crossref =     "ISSTA2011",
  pages = 	 "353--363",
  abstract =
   "In an object-oriented program, a unit test often consists of a sequence of
    method calls that create and mutate objects, then use them as arguments to
    a method under test.  It is challenging to automatically generate sequences
    that are \textit{legal} and \textit{behaviorally-diverse}, that is,
    reaching as many different program states as possible.
    \par
    This paper proposes a combined static and dynamic automated test generation
    approach to address these problems, for code without a formal
    specification. Our approach first uses dynamic analysis to infer a call
    sequence model from a sample execution, then uses static analysis to
    identify method dependence relations based on the fields they may read or
    write. Finally, both the dynamically-inferred model (which tends to be
    accurate but incomplete) and the statically-identified dependence
    information (which tends to be conservative) guide a random test generator
    to create legal and behaviorally-diverse tests.
    \par
    Our Palus tool implements this testing approach. We compared its
    effectiveness with a pure random approach, a dynamic-random approach
    (without a static phase), and a static-random approach (without a dynamic
    phase) on several popular open-source Java programs. Tests generated by
    Palus achieved higher structural coverage and found more bugs.
    \par
    Palus is also internally used in Google. It has found 22 previously-unknown
    bugs in four well-tested Google products.",
  basefilename = "palus-testgen-issta2011",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/palus-testgen-issta2011.pdf PDF;
    https://homes.cs.washington.edu/~mernst/pubs/palus-testgen-issta2011.pdf slides (PDF);
    https://homes.cs.washington.edu/~mernst/pubs/palus-testgen-issta2011.pdf slides (PowerPoint)",
  downloads = "https://code.google.com/archive/p/tpalus/ implementation",
  OPTsupersededby = "",
  category = "Test generation",
  csetags = "szhang,ybu,mernst,mernst-Testing,plse,proj-testgen",
  summary =
   "The Palus tool performs constraint-based random test generations, using
    constraints learned from dynamic executions and from static analysis of
    method coupling.  Palus outperforms all other known test generation
    approaches, and found real bugs in well-tested commercial software.",
}


@InProceedings{GaneshKAGHE2011,
  author = 	 "Vijay Ganesh and Adam Kie{\.z}un and Shay Artzi and Philip J. Guo and Pieter Hooimeijer and Michael D. Ernst",
  authorASCII = 	 "Vijay Ganesh and Adam Kiezun and Shay Artzi and Philip J. Guo and Pieter Hooimeijer and Michael D. Ernst",
  title = 	 "HAMPI: a string solver for testing, analysis and vulnerability detection",
  crossref =     "CAV2011",
  pages = 	 "1--19",
  abstract =
   "Many automatic testing, analysis, and verification techniques for programs
    can effectively be reduced to a constraint-generation phase followed by a
    constraint-solving phase. This separation of concerns often leads to more
    effective and maintainable software reliability tools. The increasing
    efficiency of offthe-shelf constraint solvers makes this approach even more
    compelling. However, there are few effective and sufficiently expressive
    off-the-shelf solvers for string constraints generated by analysis of
    string-manipulating programs, and hence researchers end up implementing
    their own ad-hoc solvers. Thus, there is a clear need for an effective and
    expressive string-constraint solver that can be easily integrated into a
    variety of applications.
    \par
    To fulfill this need, we designed and implemented Hampi, an efficient and
    easy-to-use string solver. Users of the Hampi string solver specify
    constraints using membership predicate over regular expressions,
    context-free grammars, and equality/dis-equality between string
    terms. These terms are constructed out of string constants, bounded string
    variables, and typical string operations such as concatenation and
    substring extraction. Hampi takes such a constraint as input and decides
    whether it is satisfiable or not. If an input constraint is satisfiable,
    Hampi generates a satsfying assignment for the string variables that occur
    in it.
    \par
    We demonstrate Hampi's expressiveness and efficiency by applying it to
    program analysis and automated testing: We used Hampi in static and dynamic
    analyses for finding SQL injection vulnerabilities in Web applications with
    hundreds of thousands of lines of code.We also used Hampi in the context of
    automated bug finding in C programs using dynamic systematic testing (also
    known as concolic testing). Hampi's source code, documentation, and
    experimental data are available at
    \url{https://people.csail.mit.edu/akiezun/hampi/}",
  supersededby = "KiezunGGHE2009 A tutorial and paper",
  category = "Static analysis",
  csetags = "mernst,mernst-Static-analysis,plse",
  summary =
   "This invited paper accompanies a tutorial and further describes the HAMPI solver
    (decision procedure) for string constraints such as language membership.
    Such a solver is useful when analyzing programs that manipulate strings.",
}


@InProceedings{DietlEM2011,
  author = 	 "Werner Dietl and Michael D. Ernst and Peter M{\"u}ller",
  authorASCII =	 "Werner Dietl and Michael D. Ernst and Peter Muller",
  authorASCII =	 "Werner Dietl and Michael D. Ernst and Peter Mueller",
  title = 	 "Tunable static inference for {Generic} {Universe} {Types}",
  crossref =     "ECOOP2011",
  pages = 	 "333--357",
  abstract =
   "Object ownership is useful for many applications, including program
    verification, thread synchronization, and memory management.  However, the
    annotation overhead of ownership type systems hampers their widespread
    application.  This paper addresses this issue by presenting a tunable
    static type inference for Generic Universe Types.  In contrast to classical
    type systems, ownership types have no single most general typing.  Our
    inference chooses among the legal typings via heuristics.  Our inference is
    tunable: users can indicate a preference for certain typings by adjusting
    the heuristics or by supplying partial annotations for the program.  We
    present how the constraints of Generic Universe Types can be encoded as a
    boolean satisfiability (SAT) problem and how a weighted Max-SAT solver
    finds a correct Universe typing that optimizes the weights.  We implemented
    the static inference tool, applied our inference tool to four real-world
    applications, and inferred interesting ownership structures.",
  basefilename = "tunable-typeinf-ecoop2011",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/tunable-typeinf-ecoop2011.pdf PDF;
    https://homes.cs.washington.edu/~mernst/pubs/tunable-typeinf-ecoop2011-slides.pdf slides (PDF)",
  downloads = "https://ece.uwaterloo.ca/~wdietl/inference/ Implementation and experiments",
  OPTsupersededby = "",
  category = "Ownership (encapsulation)",
  csetags = "wmd,mernst,mernst-Programming-language-design,plse",
  summary =
   "Type inference for ownershup types is underconstrained:  many different
    solutions are legal.  This paper transforms the inference problem into an
    instance of Weighted Max-SAT to find a good inference solution.",
}


@InProceedings{BrunHEN2011,
  author = 	 "Yuriy Brun and Reid Holmes and Michael D. Ernst and David Notkin",
  title = 	 "Proactive detection of collaboration conflicts",
  crossref =     "FSE2011",
  pages = 	 "168--178",
  OPTnote = 	 "",
  OPTannote = 	 "",
  abstract =
   "Collaborative development can be hampered when conflicts arise
    because developers have inconsistent copies of a shared project.
    We present an approach to help developers identify and resolve
    conflicts early, before those conflicts become severe and before
    relevant changes fade away in the developers' memories.  This paper
    presents three results.
    \par
    First, a study of open-source systems establishes that conflicts
    are frequent, persistent, and appear not only as overlapping
    textual edits but also as subsequent build and test failures.
    The study spans nine open-source systems totaling 3.4 million
    lines of code; our conflict data is derived from 550,000
    development versions of the systems.
    \par
    Second, using previously-unexploited information, we precisely
    diagnose important classes of conflicts using the novel technique
    of speculative analysis over version control operations.
    \par
    Third, we describe the design of Crystal, a publicly-available
    tool that uses speculative analysis to make concrete advice
    unobtrusively available to developers, helping them identify,
    manage, and prevent conflicts.",
  supersededby = "BrunHEN2013",
  basefilename = "vc-conflicts-fse2011",
  downloads =
    "https://github.com/brunyuriy/crystalvc Crystal implementation;
     https://people.cs.umass.edu/~brun/video/Brun11esecfse/ video of talk;
     https://homes.cs.washington.edu/~mernst/pubs/vc-conflicts-fse2011-tooldemo.pdf tool demo paper (PDF)",
  category = "Speculative analysis",
  csetags = "brun,mernst,notkin,mernst-Software-engineering,plse",
  summary =
   "The Crystal tool informs a developer when his individual work can be
    safely merged with his co-workers' changes, and when his individual work
    conflicts with co-workers, by speculatively performing version control
    system operations in the background.",
}


@InProceedings{BrunHEN2011:tooldemo,
  author = 	 "Yuriy Brun and Reid Holmes and Michael D. Ernst and David Notkin",
  title = 	 "Crystal: Precise and unobtrusive conflict warnings",
  crossref =     "FSE2011",
  pages = 	 "267--277",
  abstract =
   "During collaborative development, individual developers can create
    conflicts in their copies of the code. Such conflicting edits are
    frequent in practice, and resolving them can be costly. We present
    Crystal, a tool that proactively examines developers' code and precisely
    identifies and reports on textual, compilation, and behavioral
    conflicts. When conflicts are present, Crystal enables developers
    to resolve them more quickly, and therefore at a lesser cost. When
    conflicts are absent, Crystal increases the developers' confidence
    that it is safe to merge their code. Crystal uses an unobtrusive interface
    to deliver pertinent information about conflicts. It informs
    developers about actions that would address the conflicts and about
    people with whom they should communicate.",
  supersededby = "BrunHEN2011 A tool demonstration",
  category = "Speculative analysis",
  OMITcsetagsBECAUSESUPERSEDED = "brun,mernst,notkin,mernst-Software-engineering,plse",
  summary =
   "This tool demo describes the Crystal tool, which speculatively performs
    version control operations in the background, to help a developer know
    when it is safe and desirable to share changes with other developers.",
}


@InProceedings{BeschastnikhBSSE2011,
  author = 	 "Ivan Beschastnikh and Yuriy Brun and Sigurd Schneider and Michael Sloan and Michael D. Ernst",
  title = 	 "Leveraging existing instrumentation to automatically infer invariant-constrained models",
  crossref =     "FSE2011",
  pages = 	 "267--277",
  abstract =
   "Computer systems are often difficult to debug and understand.  A
    common way of gaining insight into system behavior is to inspect
    execution logs and documentation. Unfortunately, manual inspection
    of logs is an arduous process and documentation is often incomplete
    and out of sync with the implementation.
    \par
    This paper presents \emph{Synoptic}, a tool that helps developers by
    inferring a concise and accurate system model. Unlike most related
    work, Synoptic does not require developer-written scenarios,
    specifications, negative execution examples, or other complex user
    input. Synoptic processes the logs most systems already produce and
    requires developers only to specify a set of regular expressions for
    parsing the logs.
    \par
    Synoptic has two unique features.  First, the model it produces
    satisfies temporal invariants mined from the logs, improving
    accuracy over related approaches.  Second, Synoptic uses refinement
    and coarsening to explore the model space.  This improves model
    efficiency and precision, compared to using just one approach.
    \par
    In this paper, we formally prove that Synoptic always produces a
    model that satisfies exactly the temporal invariants that hold in
    the log, and we argue that it does so efficiently. We empirically
    evaluate Synoptic through two user experience studies, one with a
    developer of a large, real-world system and another with 45 students
    in a distributed systems course.  Developers used Synoptic-generated
    models to verify known bugs, diagnose new bugs, and increase their
    confidence in the correctness of their systems.  None of the
    developers in our evaluation had a background in formal methods but
    were able to easily use Synoptic and detect implementation bugs in
    as little as a few minutes.",
  basefilename = "synoptic-fse2011",
  downloads =
   "https://github.com/ModelInference/synoptic Synoptic implementation;
    https://homes.cs.washington.edu/~mernst/pubs/synoptic-fse2011-tool-demo.pdf tool demo paper (PDF)",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/synoptic-fse2011.pdf PDF",
  OPTsupersededby = "",
  category = "Distributed systems,Specification inference",
  csetags = "ivanb,brun,mernst,mgsloan,mernst-Software-engineering,proj-synoptic,plse",
  summary =
   "Synoptic infers, from system logs, a finite state machine model of the
    system.  Synoptic's novel inference algorithm efficiently leads to compact
    but accurate models.  Programmers found Synoptic useful for bug detection
    and other tasks.",
  undergradCoauthor = 1,
}


@InProceedings{BeschastnikhABE2011,
  author = 	 "Ivan Beschastnikh and Jenny Abrahamson and Yuriy Brun and Michael D. Ernst",
  title = 	 "Synoptic: Studying logged behavior with inferred models",
  crossref =     "FSE2011",
  pages = 	 "448--451",
  abstract =
   "Logging is a powerful method for capturing program activity and state
    during an execution. However, log inspection remains a tedious
    activity, with developers often piecing together what went on from
    multiple log lines and across many files. This paper describes
    Synoptic, a tool that takes logs as input and outputs a finite state
    machine that models the process generating the logs. The paper
    overviews the model inference algorithms.  Then, it describes the
    Synoptic tool, which is designed to support a rich log exploration
    workflow.",
  basefilename = "synoptic-fse2011-tool-demo",
  supersededby = "BeschastnikhBSSE2011 A tool demonstration",
  category = "Specification inference",
  OMITcsetagsBECAUSESUPERSEDED = "ivanb,jabrah,brun,mernst,mernst-Software-engineering,proj-synoptic,plse",
  NEEDsummary = 	 "*",
  undergradCoauthor = 1,
}




@TechReport{GordonEG2011,
  author = 	 "Colin S. Gordon and Michael D. Ernst and Dan Grossman",
  title = 	 "Static lock capabilities for deadlock freedom",
  institution =  UWCSEDept,
  year = 	 2011,
  number = 	 "UW-CSE-11-10-01",
  address = 	 UWCSEaddr,
  month = 	 oct,
  abstract =
   "We present a technique --- lock capabilities --- for statically verifying
    that multithreaded programs with locks will not deadlock.  Most previous
    work is built around a strict total order on all locks held simultaneously
    by a thread, but such an invariant often does not hold with fine-grained
    locking, especially when data-structure mutations change the order locks
    are acquired.  Lock capabilities support idioms that use fine-grained
    locking, such as mutable binary trees, circular lists, and arrays where
    each element has a different lock.
    \par
    Lock capabilities do not enforce a total order and do not prevent external
    references to data-structure nodes.  Instead, the technique reasons about
    static capabilities, where a thread already holding locks can attempt to
    acquire another lock only if its capabilities allow it.  Acquiring one lock
    may grant a capability to acquire further locks, and in data-structures
    where heap shape affects safe locking orders, we can use the heap structure
    to induce the capability-granting relation.  Deadlock-freedom follows from
    ensuring that the capability-granting relation is acyclic.  Where
    necessary, we restrict aliasing with a variant of unique references to
    allow strong updates to the capability-granting relation, while still
    allowing other aliases that are used only to acquire locks while holding no
    locks.
    \par
    We formalize our technique as a type-and-effect system, demonstrate it
    handles realistic challenging idioms, and use syntactic techniques (type
    preservation) to show it soundly prevents deadlock.",
  basefilename = "lock-capabilities-tr111001",
  supersededby = "GordonEG2012",
  category = "Concurrency",
  csetags = "csgordon,mernst,djg,mernst-Static-analysis,plse,plse-lockcaps",
  summary =
   "This paper prevents deadlock by forcing the locking discipline to follow
    pointers in the heap (or any other tree structure).  It permits fine-grained
    locking, arbitrary lock acquisition orders, changing the locking order, etc.",
}


@InProceedings{ZhangZE2011,
  author = 	 "Sai Zhang and Cheng Zhang and Michael D. Ernst",
  title = 	 "Automated documentation inference to explain failed tests",
  crossref =     "ASE2011",
  pages = 	 "63--72",
  abstract =
   "A failed test reveals a potential bug in the tested code. Developers need
    to understand which parts of the test are relevant to the failure before
    they start bug-fixing.
    \par
    This paper presents a fully-automated technique (and its tool
    implementation, called FailureDoc) to explain a failed test.  FailureDoc
    augments the failed test with explanatory documentation in the form of code
    comments. The comments indicate changes to the test that would cause it to
    pass, helping programmers understand why the test fails.
    \par
    We evaluated FailureDoc on five real-world programs.  FailureDoc generated
    meaningful comments for most of the failed tests. The inferred comments
    were concise and revealed important debugging clues.  We further conducted
    a user study. The results showed that FailureDoc is useful in bug
    diagnosis.",
  basefilename = "test-documentation-ase2011",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/test-documentation-ase2011.pdf PDF;
    https://homes.cs.washington.edu/~mernst/pubs/test-documentation-ase2011-slides.pdf slides (PDF)",
  downloads =
   "https://code.google.com/archive/p/failuredoc/ FailureDoc implementation",
  category = "Natural language processing,Testing",
  csetags = "szhang,mernst,mernst-Testing,plse,proj-failuredoc",
  summary =
   "When a test fails, debugging begins.  The FailureDoc tool indicates which
    parts of a failed test are most relevant to the failure, which helps
    programmers to understand and fix the failure.",
}


@InProceedings{RobinsonEPAL2011,
  author = 	 "Brian Robinson and Michael D. Ernst and Jeff H. Perkins and Vinay Augustine and Nuo Li",
  title = 	 "Scaling up automated test generation: Automatically generating maintainable regression unit tests for programs",
  crossref =     "ASE2011",
  pages = 	 "23--32",
  abstract =
   "This paper presents an automatic technique for generating maintainable
    regression unit tests for programs.  We found previous test generation
    techniques inadequate for two main reasons.  First. they were designed
    for and evaluated upon libraries rather than applications.  Second, they
    were designed to find bugs rather than to create maintainable regression
    test suites:  the test suites that they generated were brittle and hard
    to understand.
    This paper presents a suite of techniques that address these problems by
    enhancing an existing unit test generation system.  In experiments using
    an industrial system, the generated tests achieved good coverage and
    mutation kill score, were readable by the product's developers, and
    required few edits as the system under test evolved.
    While our evaluation is in the context of one test generator, we are
    aware of many research systems that suffer similar limitations, so our
    approach and observations are more generally relevant.",
  basefilename = "maintainable-tests-ase2011",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/maintainable-tests-ase2011.pdf PDF",
  downloads =
   "https://randoop.github.io/randoop/ Randoop implementation",
  category = "Test generation",
  csetags = "mernst,mernst-Testing,plse",
  summary =
   "This paper shows how to apply automatic test generation to the domain of
    programs (not just libraries), and how to make the resulting test suite
    maintainable (easy to understand and to adapt to changes in the program).",
}



@InProceedings{BeschastnikhBEKA2011:SLAML,
  author = 	 "Ivan Beschastnikh and Yuriy Brun and Michael D. Ernst and Arvind Krishnamurthy and Thomas E. Anderson",
  title = 	 "Mining temporal invariants from partially ordered logs",
  crossref =     "SLAML2011",
  NOpages = 	 "*",
  note = 	 "Article No.~3",
  abstract =
   "A common assumption made in log analysis research is that the underlying
    log is totally ordered.  For concurrent systems, this assumption constrains
    the generated log to either exclude concurrency altogether, or to capture a
    particular interleaving of concurrent events. This paper argues that
    capturing concurrency as a partial order is useful and often indispensable
    for answering important questions about concurrent systems.  To this end,
    we motivate a family of event ordering invariants over partially ordered
    event traces, give three algorithms for mining these invariants from logs,
    and evaluate their scalability on simulated distributed system logs.",
  basefilename = "mining-po-logs-slaml2011",
  OMITdownloads_because_synoptic_does_not_yet_handle_partially_ordered_logs =
   "https://github.com/ModelInference/synoptic Synoptic implementation",
  supersededby = "BeschastnikhBEKA2011:OSR",
  category = "Distributed systems,Specification inference",
  csetags = "ivanb,brun,mernst,arvind,tom,mernst-Software-engineering,proj-synoptic,plse",
  summary =
   "Totally ordered (linear) logs have been well-studied in the invariant
    mining community, but many real logs (e.g., from distributed systems) are
    partially ordered.  This paper gives algorithms for mining invariants from
    partially ordered logs.",
}


@InProceedings{BeschastnikhBEKA2011:SOSP-WIP,
  author = 	 "Ivan Beschastnikh and Yuriy Brun and Michael D. Ernst and Arvind Krishnamurthy and Thomas E. Anderson",
  title = 	 "Bandsaw: Log-powered test scenario generation for distributed systems",
  crossref =     "SOSPWIP2011",
  NEEDpages = 	 "*",
  NOabstract =  "*",
  basefilename = "log-test-gen-sospwip2011",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/log-test-gen-sospwip2011.pdf PDF",
  OPTsupersededby = "",
  category = "Distributed systems,Specification inference",
  csetags = "ivanb,brun,mernst,arvind,tom,mernst-Software-engineering,proj-synoptic,plse",
  summary =
   "This short paper proposes a way to automatically generate test scenarios
    (and eventually full tests), by mining existing logs, modeling the results,
    and generating new traces from the models.",
}


@Article{BeschastnikhBEKA2011:OSR,
  author = 	 "Ivan Beschastnikh and Yuriy Brun and Michael D. Ernst and Arvind Krishnamurthy and Thomas E. Anderson",
  title = 	 "Mining temporal invariants from partially ordered logs",
  journal = 	 OSR,
  year = 	 2011,
  volume = 	 45,
  number = 	 3,
  pages = 	 "39--46",
  month = 	 dec,
  abstract =
   "A common assumption made in log analysis research is that the underlying
    log is totally ordered. For concurrent systems, this assumption constrains
    the generated log to either exclude concurrency altogether, or to capture a
    particular interleaving of concurrent events. This paper argues that
    capturing concurrency as a partial order is useful and often indispensable
    for answering important questions about concurrent systems. To this end, we
    motivate a family of event ordering invariants over partially ordered event
    traces, give three algorithms for mining these invariants from logs, and
    evaluate their scalability on simulated distributed system logs.",
  basefilename = "mining-po-logs-osr2011",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/mining-po-logs-osr2011.pdf PDF",
  OMITdownloads_because_synoptic_does_not_yet_handle_partially_ordered_logs =
   "https://github.com/ModelInference/synoptic Synoptic implementation",
  category = "Distributed systems,Specification inference",
  csetags = "ivanb,brun,mernst,arvind,tom,mernst-Software-engineering,proj-synoptic,plse",
  summary =
   "Totally ordered (linear) logs have been well-studied in the invariant
    mining community, but many real logs (e.g., from distributed systems) are
    partially ordered.  This paper gives algorithms for mining invariants from
    partially ordered logs.",
}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%% 2012
%%%

@InProceedings{GordonEG2012,
  author = 	 "Colin S. Gordon and Michael D. Ernst and Dan Grossman",
  title = 	 "Static lock capabilities for deadlock freedom",
  crossref =     "TLDI2012",
  pages = 	 "67--78",
  abstract =
   "We present a technique --- lock capabilities --- for statically verifying
    that multithreaded programs with locks will not deadlock.  Most previous
    work on deadlock prevention requires a strict total order on all locks held
    simultaneously by a thread, but such an invariant often does not hold with
    fine-grained locking, especially when data-structure mutations change the
    order locks are acquired.  Lock capabilities support idioms that use
    fine-grained locking, such as mutable binary trees, circular lists, and
    arrays where each element has a different lock.
    \par
    Lock capabilities do not enforce a total order and do not prevent external
    references to data-structure nodes.  Instead, the technique reasons about
    static capabilities, where a thread already holding locks can attempt to
    acquire another lock only if its capabilities allow it.  Acquiring one lock
    may grant a capability to acquire further locks; in data-structures where
    heap shape affects safe locking orders, the heap structure can induce the
    capability-granting relation.  Deadlock-freedom follows from ensuring that
    the capability-granting relation is acyclic.  Where necessary, we restrict
    aliasing with a variant of unique references to allow strong updates to the
    capability-granting relation, while still allowing other aliases that are
    used only to acquire locks while holding no locks.
    \par
    We formalize our technique as a type-and-effect system, demonstrate it
    handles realistic challenging idioms, and use syntactic techniques (type
    preservation) to show it soundly prevents deadlock.",
  basefilename = "lock-capabilities-tldi2012",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/lock-capabilities-tldi2012.pdf PDF;
    https://homes.cs.washington.edu/~mernst/pubs/lock-capabilities-tldi2012-slides.pdf slides (PDF)",
  category = "Concurrency",
  csetags = "csgordon,mernst,djg,mernst-Static-analysis,plse,plse-lockcaps",
  summary =
   "This paper prevents deadlock by forcing the locking discipline to follow
    pointers in the heap (or any other tree structure).  It permits fine-grained
    locking, arbitrary lock acquisition orders, changing the locking order, etc.",
}


@InProceedings{BrunMHEN2012,
  author = 	 "Yuriy Brun and K{\i}van{\c{c}} Mu{\c{s}}lu and Reid Holmes and Michael D. Ernst and David Notkin",
  authorASCII =  "Yuriy Brun and Kivanc Muslu and Reid Holmes and Michael D. Ernst and David Notkin",
  title = 	 "Predicting development trajectories to prevent collaboration conflicts",
  crossref =     "FutureCSD2012",
  NEEDpages = 	 "*",
  abstract =
   "The benefits of collaborative development are reduced by the cost of
    resolving conflicts.  We posit that reducing the time between when
    developers introduce and learn about conflicts reduces this cost.  We
    outline the state-of-the-practice of managing and resolving conflicts and
    describe how it can be improved by available state-of-the-art tools.  Then,
    we describe our vision for future tools that can predict likely conflicts
    before they are even created, warning developers and allowing them to avoid
    potentially costly situations.",
  basefilename = "speculate-predict-fcsd2012",
  downloads =
   "https://homes.cs.washington.edu/~mernst/pubs/speculate-predict-fcsd2012-poster.pptx poster (PowerPoint)",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/speculate-predict-fcsd2012.pdf PDF",
  category = "Speculative analysis",
  csetags = "brun,kivanc,mernst,notkin,mernst-Software-engineering,plse,plse-speculation",
  summary =
   "Rather than dealing with source code conflicts when a developer notices,
    or using a tool to detect them as soon as they arise, it is better
    to predict and prevent them before they happen.",
}


@InProceedings{LiE2012,
  author = 	 "Jingyue Li and Michael D. Ernst",
  title = 	 "{CBCD}: {Cloned} {Buggy} {Code} {Detector}",
  crossref =     "ICSE2012",
  pages = 	 "310--320",
  abstract =
   "Developers often copy, or clone, code in order to reuse or modify
    functionality. When they do so, they also clone any bugs in the original
    code. Or, different developers may independently make the same mistake. As
    one example of a bug, multiple products in a product line may use a
    component in a similar wrong way. This paper makes two contributions.
    First, it presents an empirical study of cloned buggy code. In a large
    industrial product line, about 4\% of the bugs are duplicated across more
    than one product or file. In three open source projects (the Linux kernel,
    the Git version control system, and the PostgreSQL database) we found 282,
    33, and 33 duplicated bugs, respectively. Second, this paper presents a
    tool, CBCD, that searches for code that is semantically identical to given
    buggy code. CBCD tests graph isomorphism over the Program Dependency Graph
    (PDG) representation and uses four optimizations. We evaluated CBCD by
    searching for known clones of buggy code segments in the three projects and
    compared the results with text-based, token-based, and AST-based code clone
    detectors, namely Simian, CCFinder, Deckard, and CloneDR\@. The evaluation
    shows that CBCD is fast when searching for possible clones of the buggy
    code in a large system, and it is more precise for this purpose than the
    other code clone detectors.",
  basefilename = "buggy-clones-icse2012",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/buggy-clones-icse2012.pdf PDF",
  downloads =
   "https://homes.cs.washington.edu/~mernst/pubs/buggy-clones-tr110502.pdf TR UW-CSE-11-05-02",
  category = "Defect prediction",
  csetags = "mernst,mernst-Software-engineering,plse",
  summary =
   "When programmers clone code, they also clone bugs.  This paper presents a
    technique to find clones of just-fixed bugs, so the clones can also be fixed.",
}



@InProceedings{MusluBHEN2012-ICSENIER,
  author = 	 "K{\i}van{\c{c}} Mu{\c{s}}lu and Yuriy Brun and Reid Holmes and Michael D. Ernst and David Notkin",
  authorASCII =  "Kivanc Muslu and Yuriy Brun and Reid Holmes and Michael D. Ernst and David Notkin",
  title = 	 "Improving {IDE} recommendations by considering global implications of existing recommendations",
  crossref =     "ICSENIER2012",
  pages = 	 "1349--1352",
  abstract =
   "Modern integrated development environments (IDEs) offer recommendations to
    aid development, such as auto-completions, refactorings, and fixes for
    compilation errors.  Recommendations for each code location are typically
    computed independently of the other locations.  We propose that an IDE
    should consider the whole codebase, not just the local context, before
    offering recommendations for a particular location.  We demonstrate the
    potential benefits of our technique by presenting four concrete scenarios
    in which the Eclipse IDE fails to provide proper Quick Fixes at relevant
    locations, even though it offers those fixes at other locations.  We
    describe a technique that can augment an existing IDE's recommendations to
    account for non-local information.  For example, when some compilation
    errors depend on others, our technique helps the developer decide which
    errors to resolve first.",
  basefilename = "global-recommendations-icsenier2012",
  downloads = "https://github.com/brunyuriy/quick-fix-scout Quick Fix Scout implementation",
  OPTdownloadsnonlocal = "",
  supersededby = "MusluBHEN2012-OOPSLA",
  category = "Speculative analysis",
  summary =
   "Integrated development environments (IDEs) offer suggestions to programmers;
    accepting these suggestions can speed development.  This paper improves
    current recommendation systems by performing global analysis of the
    consequences of each suggestion.",
}





@InProceedings{SpishakDE2012,
  author = 	 "Eric Spishak and Werner Dietl and Michael D. Ernst",
  title = 	 "A type system for regular expressions",
  crossref =     "FTFJP2012",
  pages = 	 "20--26",
  abstract =
   "Regular expressions are used to match and extract text.  It is easy
    for developers to make syntactic mistakes when writing regular
    expressions, because regular expressions are often complex and
    different across programming languages.  Such errors result in
    exceptions at run time, and there is currently no static support for
    preventing them.
    \par
    This paper describes practical experience designing and using a type
    system for regular expressions.  This type system validates regular
    expression syntax and capturing group usage at compile time instead of
    at run time --- ensuring the absence of \texttt{PatternSyntaxException}s
    from invalid syntax and \texttt{IndexOutOfBoundsException}s from accessing
    invalid capturing groups.
    \par
    Our implementation is publicly available and supports the full Java language.
    In an evaluation on five open-source Java
    applications (480kLOC), the type system was
    easy to use, required less than one annotation per two thousand lines, and
    found 56 previously-unknown bugs.",
  basefilename = "regex-types-ftfjp2012",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/regex-types-ftfjp2012.pdf PDF;
    https://homes.cs.washington.edu/~mernst/pubs/regex-types-ftfjp2012-slides.pdf slides (PDF)",
  downloads =
   "https://checkerframework.org/manual/#regex-checker Regex Checker implementation",
  category = "Verification",
  csetags = "espishak,wmdietl,mernst,mernst-Programming-language-design,plse",
  summary =
   "A program that uses regular expressions can fail at run time due to improper
    regex syntax or due to access of a non-existent capturing group.  This paper
    presents a type system that detects and prevents such errors at compile time.",
  undergradCoauthor = 1,
}


@InProceedings{DietlDEMWCPP2012,
  author = 	 "Werner Dietl and Stephanie Dietzel and Michael D. Ernst and Nathaniel Mote and Brian Walker and Seth Cooper and Timothy Pavlik and Zoran Popovi{\'c}",
  authorASCII = 	 "Werner Dietl and Stephanie Dietzel and Michael D. Ernst and Nathaniel Mote and Brian Walker and Seth Cooper and Timothy Pavlik and Zoran Popovic",
  title = 	 "Verification games: Making verification fun",
  crossref =     "FTFJP2012",
  pages = 	 "42--49",
  abstract =
   "Program verification is the only way to be certain that a given piece of
    software is free of (certain types of) errors --- errors that could
    otherwise disrupt operations in the field.  To date, formal verification
    has been done by specially-trained engineers.  Labor costs have heretofore
    made formal verification too costly to apply beyond small, critical
    software components.
    \par
    Our goal is to make verification more cost-effective by reducing the skill
    set required for program verification and increasing the pool of people
    capable of performing program verification.  Our approach is to transform
    the verification task (a program and a goal property) into a visual puzzle
    task --- a game --- that gets solved by people. The solution of the puzzle
    is then translated back into a proof of correctness.  The puzzle is
    engaging and intuitive enough that ordinary people can through game-play
    become experts.
    \par
    This paper presents a status report on the Verification Games project and
    our Pipe Jam prototype game.",
  basefilename = "verigames-ftfjp2012",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/verigames-ftfjp2012.pdf PDF;
    https://homes.cs.washington.edu/~mernst/pubs/verigames-ftfjp2012-slides.pdf slides (PDF)",
  OLDdownloads =
   "https://www.cs.washington.edu/verigames/ project homepage;
    https://games.cs.washington.edu/verigame/PipeJam-20111012.mp4 video;
    https://games.cs.washington.edu/verigames-dev/demo/pipes/webgame.php?sample=sample.zip Pipe Jam game;
    https://games.cs.washington.edu/verigames-dev/demo/traffic/PipeJam.html Traffic Jam game;
    https://games.cs.washington.edu/verigame/flowjam/ Flow Jam game;
    https://paradox.centerforgamescience.org/paradox/Paradox.html Paradox game",
  category = "Verification",
  csetags = "wmdietl,sdietzel,mernst,nmote,bdwalker,scooper,pavlik,zoran,mernst-verification,plse,graphics,plse-verigames",
  summary =
   "This paper presents a system that takes as input a program and a property,
    and produces as output a game.  When a player finishes a level of the game,
    the final configuration of board elements can be translated to a proof of
    the property.",
  undergradCoauthor = 1,
}





@InProceedings{HuangDME2012,
  author = 	 "Wei Huang and Werner Dietl and Ana Milanova and Michael D. Ernst",
  title = 	 "Inference and checking of object ownership",
  crossref =     "ECOOP2012",
  pages = 	 "181--206",
  abstract =
   "Ownership type systems describe a heap topology and enforce an
    encapsulation discipline; they aid in various program correctness and
    understanding tasks.  However, the annotation overhead of ownership type
    systems has hindered their widespread use.  We present a unified framework
    for specification, type inference and type checking of ownership type
    systems, and instantiate the framework for two such systems: Universe Types
    and Ownership Types.  We present an objective metric defining a ``best
    typing'' for these type systems, and develop an inference approach that
    maximizes the metric.  The programmer can influence the inference by adding
    partial annotations to the program.  We implemented the approach on top of
    the Checker Framework and present the results of an experimental
    evaluation.",
  basefilename = "infer-ownership-ecoop2012",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/infer-ownership-ecoop2012.pdf PDF;
    https://homes.cs.washington.edu/~mernst/pubs/infer-ownership-ecoop2012-slides.pdf slides (PDF)",
  downloads =
   "https://github.com/proganalysis/type-inference implementation",
  category = "Ownership (encapsulation)",
  csetags = "wmdietl,mernst,mernst-Static-analysis,plse",
  summary =
   "This paper generalizes previous work on ownership inference, showing how
    a single algorithm can apply to multiple ownership type systems and choose
    a desirable typing among many possible ones.",
}



@InProceedings{Ernst2012:ICST,
  author = 	 "Michael D. Ernst",
  title = 	 "Reproducible tests?  Non-duplicable results in testing and verification",
  crossref =     "ICST2012",
  pages = 	 "xlvix",
  abstract =
   "Reproducibility is a central tenet of testing.  Randomization in test
    outputs could mask the signal that indicates correctness, so engineers work
    to ensure that test execution is consistent.  Proofs, too, must be
    reproducible:  a proof is of little value unless it can be independently
    verified.
    \par
    Evaluation of tools and processes does not meet the standards that
    engineers expect in their software.  Random testing is sometimes found to
    be superior to, sometimes inferior to, systematic testing.  High
    test-coverage goals are adopted by one organization but abandoned by
    another.  Test-first development strategies help one project but cripple
    another.  Formal development methods (based on specification and
    verification) sometimes reduce costs but other times increase them, with
    varying correlation to quality.  Programmers sing the praises of improved
    productivity when adopting languages with strong type systems --- or
    languages without static typing.  There are also rifts between techniques
    that are shown effective in research laboratories and those that are
    adopted in practice:  research experiments are often not indicative of
    effectiveness in the field.  These discordant observations hold back our
    field by sowing confusion among researchers and doubt among practitioners,
    and by preventing common ground within or between the communities.  The
    divergences continue to occur despite our best intentions, and despite our
    increasing sophistication in tool-building, evaluation, realistic
    codebases, education, bridging communities, and the like.
    \par
    This talk will illustrate the scope of the problem with examples of
    conflicting results and experiences in the testing, verification, and
    validation community.  It will discuss reasons for non-reproducibility ---
    some of which are standard and acknowledged, and others of which are more
    subtle and easily overlooked.  It will discuss ways to avoid or mitigate
    the problems.  This talk aims to help the audience to recognize
    non-reproducible results in their own work or that of others, and to avoid
    them whether in research or in practice.",
  basefilename = "unreproducible-tests-icst-2012",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/unreproducible-tests-icst-2012-slides.pdf slides (PDF)",
  category = "Software engineering",
  summary =
   "This keynote talk is a call to arms to the community to treat research more
    like software:  it deserves to be tested and replicable."
}



@Article{BuHBErnst2012,
  author = 	 "Yingyi Bu and Bill Howe and Magdalena Balazinska and Michael D. Ernst",
  title = 	 "The {HaLoop} approach to large-scale iterative data analysis",
  journal = 	 "The VLDB Journal",
  year = 	 2012,
  volume = 	 21,
  number = 	 2,
  pages = 	 "169--190",
  abstract =
   "The growing demand for large-scale data mining and data analysis
    applications has led both industry and academia to design new types of
    highly scalable data-intensive computing platforms. MapReduce has enjoyed
    particular success. However, MapReduce lacks built-in support for iterative
    programs, which arise naturally in many applications including data mining,
    web ranking, graph analysis, and model fitting. This paper (This is an
    extended version of the VLDB 2010 paper ``HaLoop: Efficient Iterative Data
    Processing on Large Clusters'' PVLDB 3(1):285--296, 2010.) presents HaLoop, a
    modified version of the Hadoop MapReduce framework, that is designed to
    serve these applications. HaLoop allows iterative applications to be
    assembled from existing Hadoop programs without modification, and
    significantly improves their efficiency by providing inter-iteration
    caching mechanisms and a loop-aware scheduler to exploit these
    caches. HaLoop retains the fault-tolerance properties of MapReduce through
    automatic cache recovery and task re-execution. We evaluated HaLoop on a
    variety of real applications and real datasets. Compared with Hadoop, on
    average, HaLoop improved runtimes by a factor of 1.85 and shuffled only 4\%
    as much data between mappers and reducers in the applications that we
    tested.",
  basefilename = "haloop-vldb2012",
  downloads =
   "https://homes.cs.washington.edu/~mernst/pubs/haloop-vldb2010-slides.pdf VLDB 2010 slides (PDF);
    https://homes.cs.washington.edu/~mernst/pubs/haloop-vldb2010-slides.ppt VLDB 2010 slides (PowerPoint);
    https://code.google.com/archive/p/haloop/ HaLoop implementation",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/haloop-vldb2012.pdf PDF",
  FUTUREcategory =  "Databases",
  category = "Miscellaneous",
  csetags = "ybu,billhowe,magda,mernst,mernst-Miscellaneous,plse",
  summary =
   "An iterative job may repeat similar work on each iteration.  This paper
    shows how to avoid repeating work in iterative MapReduce jobs,
    substantially improving performance.",
}


@InProceedings{ZhangLE2012,
  author = 	 "Sai Zhang and Hao L{\"u} and Michael D. Ernst",
  authorASCII =	 "Sai Zhang and Hao Lu and Michael D. Ernst",
  title = 	 "Finding errors in multithreaded {GUI} applications",
  crossref =     "ISSTA2012",
  pages = 	 "243--253",
  abstract =
   "To keep a Graphical User Interface (GUI) responsive and active, a GUI
    application often has a main \textit{UI thread} (or \textit{event
    dispatching thread}) and spawns separate threads to handle lengthy
    operations in the background, such as expensive computation, I/O tasks, and
    network requests.  Many GUI frameworks require all GUI objects to be
    accessed exclusively by the UI thread. If a GUI object is accessed from a
    non-UI thread, an \textit{invalid thread access} error occurs and the whole
    application may abort.
    \par
    This paper presents a general technique to find such \textit{invalid thread
    access} errors in multithreaded GUI applications. We formulate finding
    invalid thread access errors as a call graph reachability problem with
    thread spawning as the sources and GUI object accessing as the sinks.
    Standard call graph construction algorithms fail to build a good call graph
    for some modern GUI applications, because of heavy use of reflection.
    Thus, our technique builds reflection-aware call graphs.
    \par
    We implemented our technique and instantiated it for four popular Java GUI
    frameworks: SWT, the Eclipse plugin framework, Swing, and Android. In an
    evaluation on 9 programs comprising 89273 LOC, our technique found 5
    previously-known errors and 5 new ones.",
  basefilename = "gui-thread-issta2012",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/gui-thread-issta2012.pdf PDF;
    https://homes.cs.washington.edu/~mernst/pubs/gui-thread-issta2012-slides.pdf slides (PDF);
    https://homes.cs.washington.edu/~mernst/pubs/gui-thread-tr130401.pdf extended version (PDF)",
  csetags = "mernst,mernst-Testing,plse,plse-testing,szhang",
  downloads = "https://github.com/zhang-sai/guierrordetector implementation",
  category = "Concurrency,User interfaces,Mobile applications",
  summary =
   "In a GUI program, only the main thread (event thread) should access GUI
    objects.  Our analysis verifies this property, and found crashing errors
    in Android, Eclipse plugin, Swing, and SWT applications.",
}



@TechReport{BeschastnikhBAEK2012,
  author = 	 "Ivan Beschastnikh and Yuriy Brun and Jenny Abrahamson and Michael D. Ernst and Arvind Krishnamurthy",
  title = 	 "Unifying {FSM}-inference algorithms through declarative specification",
  institution =  UWCSEDept,
  year = 	 2012,
  number = 	 "UW-CSE-12-08-02",
  address = 	 UWCSEaddr,
  month = 	 aug,
  abstract =
   "Logging system behavior is a staple development practice. Numerous powerful
    model inference algorithms have been proposed to aid developers in log
    analysis and system understanding. Unfortunately, existing algorithms are
    difficult to understand, extend, and compare. This paper presents
    InvariMint, an approach to specify model inference algorithms
    declaratively. We apply InvariMint to two model inference algorithms and
    present evaluation results to illustrate that InvariMint (1) leads to new
    fundamental insights and better understanding of existing algorithms, (2)
    simplifies creation of new algorithms, including hybrids that extend
    existing algorithms, and (3) makes it easy to compare and contrast
    previously published algorithms. Finally, InvariMint's declarative approach
    can outperform equivalent procedural algorithms.",
  basefilename = "invarimint-tr120802",
  supersededby = "BeschastnikhBAEK2013",
  category = "Specification inference",
  csetags = "ivanb,brun,mernst,arvind,mernst-Software-engineering,proj-synoptic,plse",
  summary =
   "Model inference algorithms are typically defined procedurally, which makes
    it hard to understand their properties and to define new algorithms with
    specific properties.  InvariMint is a declarative approach that permits an
    algorithm designer to specify the properties of the final algorithm.",
  undergradCoauthor = 1,
}

@InProceedings{MusluBHEN2012-OOPSLA,
  author = 	 "K{\i}van{\c{c}} Mu{\c{s}}lu and Yuriy Brun and Reid Holmes and Michael D. Ernst and David Notkin",
  authorASCII =  "Kivanc Muslu and Yuriy Brun and Reid Holmes and Michael D. Ernst and David Notkin",
  title = 	 "Speculative analysis of integrated development environment recommendations",
  crossref =     "OOPSLA2012",
  pages = 	 "669--682",
  abstract =
   "Modern integrated development environments make recommendations and
    automate common tasks, such as refactorings, auto-completions, and error
    corrections.  However, these tools present little or no information about
    the consequences of the recommended changes.  For example, a rename
    refactoring may:  modify the source code without changing program
    semantics; modify the source code and (incorrectly) change program
    semantics; modify the source code and (incorrectly) create compilation
    errors; show a name collision warning and require developer input; or show
    an error and not change the source code.  Having to compute the
    consequences of a recommendation --- either mentally or by making source
    code changes --- puts an extra burden on the developers.
    \par
    This paper aims to reduce this burden with a technique that informs
    developers of the consequences of code transformations.  Using Eclipse
    Quick Fix as a domain, we describe a plug-in, Quick Fix Scout, that
    computes the consequences of Quick Fix recommendations.  In our
    experiments, developers completed compilation-error removal tasks 10\%
    faster when using Quick Fix Scout than Quick Fix, although the sample size
    was not large enough to show statistical significance.",
  basefilename = "quick-fix-scout-oopsla2012",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/quick-fix-scout-oopsla2012.pdf PDF;
    https://homes.cs.washington.edu/~mernst/pubs/quick-fix-scout-oopsla2012-slides.pdf slides (PDF)",
  downloads = "https://github.com/brunyuriy/quick-fix-scout implementation",
  category = "Speculative analysis",
  csetags = "kivanc,brun,notkin,mernst,mernst-Software-engineering,plse,plse-speculation",
  summary =
   "An IDE lets a developer modify his or her program, but does not indicate
    the consequences of those changes.  Our tool, Quick Fix Scout, shows the
    consequences of Eclipse's Quick Fix recommendations, in terms of compilation
    errors introduced or eliminated.  It makes developers faster in eliminating
    compilation errors.",
}


@InProceedings{SchillerE2012,
  author = 	 "Todd W. Schiller and Michael D. Ernst",
  title = 	 "Reducing the barriers to writing verified specifications",
  crossref =     "OOPSLA2012",
  pages = 	 "95--112",
  abstract =
   "Formally verifying a program requires significant skill not only because of
    complex interactions between program subcomponents, but also because of
    deficiencies in current verification interfaces. These skill barriers make
    verification economically unattractive by preventing the use of
    less-skilled (less-expensive) workers and distributed workflows (i.e.,
    crowdsourcing).
    \par
    This paper presents VeriWeb, a web-based IDE for verification that
    decomposes the task of writing verifiable specifications into manageable
    subproblems. To overcome the information loss caused by task decomposition,
    and to reduce the skill required to verify a program, VeriWeb incorporates
    several innovative user interface features: drag and drop condition
    construction, concrete counterexamples, and specification inlining.
    \par
    To evaluate VeriWeb, we performed three experiments.  First, we show that
    VeriWeb lowers the time and monetary cost of verification by performing a
    comparative study of VeriWeb and a traditional tool using 14 paid subjects
    contracted hourly from Exhedra Solution's vWorker online marketplace.
    Second, we demonstrate the dearth and insufficiency of current ad-hoc labor
    marketplaces for verification by recruiting workers from Amazon's
    Mechanical Turk to perform verification with VeriWeb.  Finally, we
    characterize the minimal communication overhead incurred when VeriWeb is
    used collaboratively by observing two pairs of developers each use the tool
    simultaneously to verify a single program.",
  usesDaikon = 1,
  basefilename = "veriweb-oopsla2012",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/veriweb-oopsla2012.pdf PDF;
    https://homes.cs.washington.edu/~mernst/pubs/veriweb-oopsla2012-slides.pdf slides (PDF)",
  downloads = "https://plse.cs.washington.edu/veriweb/ study materials",
  category = "User interfaces,Verification",
  csetags = "tws,mernst,mernst-Software-engineering,plse,proj-veriweb",
  summary =
   "We present a novel user interface that enables ordinary developers, who
    have not been trained in formal verification, to perform such tasks
    quickly and efficiently.  It also decomposes verification tasks, enabling
    multiple developers to collaborate.",
}


@InProceedings{HuangMDE2012,
  author = 	 "Wei Huang and Ana Milanova and Werner Dietl and Michael D. Ernst",
  title = 	 "{ReIm} \& {ReImInfer}: Checking and inference of reference immutability and method purity",
  crossref =     "OOPSLA2012",
  pages = 	 "879--896",
  abstract =
   "\emph{Reference immutability} ensures that a reference is not used to
    modify the referenced object, and enables the safe sharing of object
    structures.  A \emph{pure method} does not cause side-effects on the
    objects that existed in the pre-state of the method execution.  Checking
    and inference of reference immutability and method purity enables a variety
    of program analyses and optimizations.
    \par
    We present ReIm, a type system for reference immutability, and ReImInfer, a
    corresponding type inference analysis.  The type system is concise and
    context-sensitive. The type inference analysis is precise and scalable, and
    requires no manual annotations.  In addition, we present a novel
    application of the reference immutability type system:  method purity
    inference.
    \par
    To support our theoretical results, we implemented the type system and the
    type inference analysis for Java.  We include a type checker to verify the
    correctness of the inference result. Empirical results on Java applications
    and libraries of up to 348kLOC show that our approach achieves both
    scalability and precision.",
  basefilename = "infer-refimmutability-oopsla2012",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/infer-refimmutability-oopsla2012.pdf PDF;
    https://homes.cs.washington.edu/~mernst/pubs/infer-refimmutability-oopsla2012-slides.pdf slides (PDF)",
  downloads = "https://github.com/proganalysis/type-inference implementation",
  category = "Immutability (side effects)",
  csetags = "wmdietl,mernst,mernst-Static-analysis,plse",
  summary =
   "We present a new variant of reference immutability, along with efficient
    type inference and type checking algorithms and implementations.",
}


@Article{KiezunGAGHE2012,
  author = 	 "Adam Kie{\.z}un and Vijay Ganesh and Shay Artzi and Philip J. Guo and Pieter Hooimeijer and Michael D. Ernst",
  authorASCII =  "Adam Kiezun and Vijay Ganesh and Shay Artzi and Philip J. Guo and Pieter Hooimeijer and Michael D. Ernst",
  title = 	 "{HAMPI}: A solver for word equations over strings, regular expressions, and context-free grammars",
  journal = 	 TOSEM,
  year = 	 2012,
  volume = 	 21,
  number = 	 4,
  pages = 	 "25:1--25:28",
  month = 	 nov,
  abstract =
   "Many automatic testing, analysis, and verification techniques for programs
    can be effectively reduced to a constraint-generation phase followed by a
    constraint-solving phase. This separation of concerns often leads to more
    effective and maintainable software reliability tools. The increasing
    efficiency of off-the-shelf constraint solvers makes this approach even
    more compelling. However, there are few effective and sufficiently
    expressive off-the-shelf solvers for string constraints generated by
    analysis of string-manipulating programs, so researchers end up
    implementing their own ad-hoc solvers.
    \par
    To fulfill this need, we designed and implemented Hampi, a solver for
    string constraints over bounded string variables. Users of Hampi specify
    constraints using regular expressions, context-free grammars, equality
    between string terms, and typical string operations such as concatenation
    and substring extraction. Hampi then finds a string that satisfies all the
    constraints or reports that the constraints are unsatisfiable.
    \par
    We demonstrate Hampi's expressiveness and efficiency by applying it to
    program analysis and automated testing. We used Hampi in static and dynamic
    analyses for finding SQL injection vulnerabilities in Web applications with
    hundreds of thousands of lines of code. We also used Hampi in the context
    of automated bug finding in C programs using dynamic systematic testing
    (also known as concolic testing). We then compared Hampi with another
    string solver, CFGAnalyzer, and show that Hampi is several times
    faster. Hampi's source code, documentation, and experimental data are
    available at \url{https://people.csail.mit.edu/akiezun/hampi/}",
  basefilename = "string-solver-tosem2012",
  downloads =
   "https://people.csail.mit.edu/akiezun/hampi/ HAMPI implementation and experiments;
    https://homes.cs.washington.edu/~mernst/pubs/string-solver-tosem2012.pdf ISSTA 2009 slides (PDF)",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/string-solver-tosem2012.pdf PDF",
  category = "Static analysis",
  csetags = "mernst,mernst-Static-analysis,plse",
  summary =
   "This paper describes an efficient and expressive solver (that is, a
    decision procedure) for string constraints such as language membership.
    Such a solver is useful when analyzing programs that manipulate strings.",
}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%% 2013
%%%


@TechReport{GordonEG2013:TR,
  author = 	 "Colin S. Gordon and Michael D. Ernst and Dan Grossman",
  title = 	 "Rely-guarantee references for refinement types over aliased mutable data (extended version)",
  institution =  UWCSEDept,
  year = 	 2013,
  number = 	 "UW-CSE-13-03-02",
  address = 	 UWCSEDept,
  month = 	 mar,
  supersededby = "GordonEG2013",
}


@TechReport{GordonDEG2013:TR,
  author = 	 "Colin S. Gordon and Werner Dietl and Michael D. Ernst and Dan Grossman",
  title = 	 "{JavaUI}: Effects for controlling {UI} object access (extended version)",
  institution =  UWCSEDept,
  year = 	 2013,
  number = 	 "UW-CSE-13-04-01",
  address = 	 UWCSEaddr,
  month = 	 apr,
  supersededby = "GordonDEG2013",
}


@InProceedings{ZhangE2013,
  author = 	 "Sai Zhang and Michael D. Ernst",
  title = 	 "Automated diagnosis of software configuration errors",
  crossref =     "ICSE2013",
  pages = 	 "312--321",
  abstract =
   "The behavior of a software system often depends on how that system is
    configured. Small configuration errors can lead to hard-to-diagnose
    undesired behaviors. We present a technique (and its tool implementation,
    called ConfDiagnoser) to identify the root cause of a configuration error
    --- a single configuration option that can be changed to produce desired
    behavior. Our technique uses static analysis, dynamic profiling, and
    statistical analysis to link the undesired behavior to specific
    configuration options. It differs from existing approaches in two key
    aspects: it does not require users to provide a testing oracle (to check
    whether the software functions correctly) and thus is fully automated; and
    it can diagnose both crashing and non-crashing errors.
    \par
    We evaluated ConfDiagnoser on 5 non-crashing configuration errors and 9
    crashing configuration errors from 5 configurable software systems written
    in Java. On average, the root cause was ConfDiagnoser's fifth-ranked
    suggestion; in 10 out of 14 errors, the root cause was one of the top 3
    suggestions; and more than half of the time, the root cause was the first
    suggestion.",
  basefilename = "configuration-errors-icse2013",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/configuration-errors-icse2013.pdf PDF;
    https://homes.cs.washington.edu/~mernst/pubs/configuration-errors-icse2013-slides.pdf slides (PDF)",
  downloads = "https://github.com/zhang-sai/config-errors ConfDiagnoser implementation",
  OPTdownloadsnonlocal = "",
  category = "Program repair,Testing",
  csetags = "mernst,mernst-Testing,plse,plse-testing,szhang",
  summary =
   "Sometimes, incorrect software behavior is not due to a bug, but to supplying
    an incorrect configuration option.  The ConfDiagnoser tool suggests a
    configuration option to change so that the software behaves as desired.",
}


@TechReport{BeschastnikhBAEK2013TR,
  author = 	 "Ivan Beschastnikh and Yuriy Brun and Jenny Abrahamson and Michael D. Ernst and Arvind Krishnamurthy",
  title = 	 "Unifying {FSM}-inference algorithms through declarative specification",
  institution =  UWCSEDept,
  year = 	 2013,
  number = 	 "UW-CSE-13-03-01",
  address = 	 UWCSEaddr,
  month = 	 mar,
  abstract =
   "Logging system behavior is a staple development practice. Numerous powerful
    model inference algorithms have been proposed to aid developers in log
    analysis and system understanding. Unfortunately, existing algorithms are
    difficult to understand, extend, and compare. This paper presents
    InvariMint, an approach to specify model inference algorithms
    declaratively. We apply InvariMint to two model inference algorithms and
    present evaluation results to illustrate that InvariMint (1) leads to new
    fundamental insights and better understanding of existing algorithms, (2)
    simplifies creation of new algorithms, including hybrids that extend
    existing algorithms, and (3) makes it easy to compare and contrast
    previously published algorithms. Finally, InvariMint's declarative approach
    can outperform equivalent procedural algorithms.",
  basefilename = "invarimint-tr120802",
  supersededby = "BeschastnikhBAEK2013 An extended version with proofs",
  category = "Specification inference",
  csetags = "ivanb,brun,mernst,arvind,mernst-Software-engineering,proj-synoptic,plse",
  summary =
   "Model inference algorithms are typically defined procedurally, which makes
    it hard to understand their properties and to define new algorithms with
    specific properties.  InvariMint is a declarative approach that permits an
    algorithm designer to specify the properties of the final algorithm.",
  undergradCoauthor = 1,
}


@InProceedings{BeschastnikhBAEK2013,
  author = 	 "Ivan Beschastnikh and Yuriy Brun and Jenny Abrahamson and Michael D. Ernst and Arvind Krishnamurthy",
  title = 	 "Unifying {FSM}-inference algorithms through declarative specification",
  crossref =     "ICSE2013",
  pages = 	 "252--261",
  abstract =
   "Logging system behavior is a staple development practice. Numerous powerful
    model inference algorithms have been proposed to aid developers in log
    analysis and system understanding. Unfortunately, existing algorithms are
    difficult to understand, extend, and compare. This paper presents
    InvariMint, an approach to specify model inference algorithms
    declaratively. We apply InvariMint to two model inference algorithms and
    present evaluation results to illustrate that InvariMint (1) leads to new
    fundamental insights and better understanding of existing algorithms, (2)
    simplifies creation of new algorithms, including hybrids that extend
    existing algorithms, and (3) makes it easy to compare and contrast
    previously published algorithms. Finally, InvariMint's declarative approach
    can outperform equivalent procedural algorithms.",
  basefilename = "fsm-inference-declarative-icse2013",
  downloads =
    "https://homes.cs.washington.edu/~mernst/pubs/fsm-inference-declarative-tr130301.pdf TR UW-CSE-13-03-01;
     https://github.com/ModelInference/synoptic InvariMint implementation",
  supersededby = "BeschastnikhBAEK2015",
  category = "Specification inference",
  csetags = "ivanb,brun,mernst,jabrah,arvind,mernst-Software-engineering,proj-synoptic,plse",
  summary =
   "Model inference algorithms summarize a log to make it easier to understand.
    But the algorithm itself can be hard to understand, especially if specified
    procedurally.  InvariMint gives a declarative and efficient way to specify
    model inference algorithms.",
  undergradCoauthor = 1,
}


@InCollection{PotaninOZE2013,
  author = 	 "Alex Potanin and Johan {\"O}stlund and Yoav Zibin and Michael D. Ernst",
  authorASCII =  "Alex Potanin and Johan Ostlund and Yoav Zibin and Michael D. Ernst",
  title = 	 "Immutability",
  booktitle = 	 "Aliasing in Object-Oriented Programming",
  publisher = 	 "Springer-Verlag",
  year = 	 2013,
  volume = 	 "7850",
  series = 	 "LNCS",
  pages = 	 "233--269",
  month = 	 apr,
  abstract =
   "One of the main reasons aliasing has to be controlled, as highlighted in
    another chapter of this book, is the possibility that a variable can
    unexpectedly change its value without the referrer's knowledge. This book
    will not be complete without a discussion of the impact of immutability on
    reference-abundant imperative object-oriented languages. In this chapter we
    briefly survey possible definitions of immutability and present recent work
    by the authors on adding immutability to object-oriented languages and how
    it impacts aliasing.",
  basefilename = "immutability-aliasing-2013-lncs7850",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/immutability-aliasing-2013-lncs7850.pdf PDF",
  OPTdownloads = "",
  OPTdownloadsnonlocal = "",
  category = "Immutability (side effects)",
  csetags = "mernst,mernst-Static-analysis,plse",
  summary =
   "This review chapter discusses immutability in object-oriented
   languages, with particular focus on how it impacts aliasing.",
}


@InProceedings{GordonEG2013,
  author = 	 "Colin S. Gordon and Michael D. Ernst and Dan Grossman",
  title = 	 "Rely-guarantee references for refinement types over aliased mutable data",
  crossref =     "PLDI2013",
  pages = 	 "73--84",
  abstract =
   "Reasoning about side effects and aliasing is the heart of verifying
    imperative programs.  Unrestricted side effects through one reference can
    invalidate assumptions about an alias.  We present a new type system
    approach to reasoning about safe assumptions in the presence of aliasing
    and side effects, unifying ideas from reference immutability type systems
    and rely-guarantee program logics.  Our approach, \emph{rely-guarantee
    references}, treats multiple references to shared objects similarly to
    multiple threads in rely-guarantee program logics.  We propose statically
    associating rely and guarantee conditions with individual references to
    shared objects.  Multiple aliases to a given object may coexist only if the
    guarantee condition of each alias implies the rely condition for all other
    aliases.  We demonstrate that existing reference immutability type systems
    are special cases of rely-guarantee references.
    \par
    In addition to allowing precise control over state modification,
    rely-guarantee references allow types to depend on mutable data while still
    permitting flexible aliasing.  Dependent types whose denotation is stable
    over the actions of the rely and guarantee conditions for a reference and
    its data will not be invalidated by any action through any alias.  We
    demonstrate this with refinement (subset) types that may depend on mutable
    data.  As a special case, we derive the first reference immutability type
    system with dependent types over immutable data.
    \par
    We show soundness for our approach and describe experience using
    rely-guarantee references in a dependently-typed monadic DSL in Coq.",
  basefilename = "rely-guarantee-ref-pldi2013",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/rely-guarantee-ref-pldi2013.pdf PDF;
    https://homes.cs.washington.edu/~mernst/pubs/rely-guarantee-ref-pldi2013-slides.pdf slides (PDF)",
  downloads =
   "https://homes.cs.washington.edu/~mernst/pubs/rely-guarantee-ref-tr130302.pdf technical report;
    https://github.com/csgordon/rgref/ implementation",
  category = "Immutability (side effects)",
  csetags = "csgordon,mernst,djg,mernst-Static-analysis,plse,plse-lockcaps",
  summary =
   "This paper presents a new type system for reasoning about side effects
   in the presence of aliasing.  Its technical approach unifies reference
   immutability type systems and rely-guarantee program logics.",
}


@InProceedings{GordonDEG2013,
  author = 	 "Colin S. Gordon and Werner Dietl and Michael D. Ernst and Dan Grossman",
  title = 	 "{JavaUI}: Effects for controlling {UI} object access",
  crossref =     "ECOOP2013",
  pages = 	 "179--204",
  abstract =
   "Most graphical user interface (GUI) libraries forbid accessing UI elements
    from threads other than the UI event loop thread.  Violating this
    requirement leads to a program crash or an inconsistent UI\@.  Unfortunately,
    such errors are all too common in GUI programs.
    \par
    We present a polymorphic type and effect system that prevents non-UI threads
    from accessing UI objects or invoking UI-thread-only methods. The type
    system still permits non-UI threads to hold and pass references to UI
    objects.  We implemented this type system for Java and annotated 8 Java
    programs (over 140KLOC) for the type system, including several of the most
    popular Eclipse plugins.  We confirmed bugs found by unsound prior work,
    found an additional bug and code smells, and demonstrated that the
    annotation burden is low.
    \par
    We also describe code patterns our effect system handles less gracefully or
    not at all, which we believe offers lessons for those applying other effect
    systems to existing code.",
  basefilename = "gui-thread-ecoop2013",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/gui-thread-ecoop2013.pdf PDF;
    https://homes.cs.washington.edu/~mernst/pubs/gui-thread-ecoop2013-slides.pdf slides (PDF)",
  downloads =
   "https://homes.cs.washington.edu/~mernst/pubs/gui-thread-tr20130401.pdf technical report (PDF);
    https://checkerframework.org/manual/#guieffect-checker JavaUI implementation;
    https://github.com/csgordon/javaui older implementation and annotated subject programs",
  category = "Concurrency,User interfaces",
  csetags = "csgordon,wmdietl,mernst,djg,mernst-Static-analysis,plse,plse-lockcaps",
  summary =
   "In a GUI program, only the main thread (event thread) should access GUI
    objects.  Our sound static analysis verifies this property through an
    effect system, and scaled to 140KLOC.",
}

@InProceedings{ZhangLE2013,
  author = 	 "Sai Zhang and Hao L{\"u} and Michael D. Ernst",
  authorASCII =	 "Sai Zhang and Hao Lu and Michael D. Ernst",
  title = 	 "Automatically repairing broken workflows for evolving {GUI} applications",
  crossref =     "ISSTA2013",
  pages = 	 "45--55",
  abstract =
   "A workflow is a sequence of UI actions to complete a specific task.  In the
    course of a GUI application's evolution, changes ranging from a simple GUI
    refactoring to a complete rearchitecture can break an end-user's
    well-established workflow.  It can be challenging to find a replacement
    workflow. To address this problem, we present a technique (and its tool
    implementation, called FlowFixer) that repairs a broken workflow.
    FlowFixer uses dynamic profiling, static analysis, and random testing to
    suggest a replacement UI action that fixes a broken workflow.
    \par
    We evaluated FlowFixer on 16 broken workflows from 5 real-world GUI
    applications written in Java.  In 13 workflows, the correct replacement
    action was FlowFixer's first suggestion.  In 2 workflows, the correct
    replacement action was FlowFixer's second suggestion.  The remaining
    workflow was un-repairable.  Overall, FlowFixer produced significantly
    better results than two alternative approaches.",
  basefilename = "repair-workflow-issta2013",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/repair-workflow-issta2013.pdf PDF;
    https://homes.cs.washington.edu/~mernst/pubs/repair-workflow-issta2013-slides.pdf slides (PDF)",
  downloads =
   "https://code.google.com/archive/p/workflow-repairer/ FlowFixer implementation",
  category = "Program repair,User interfaces",
  csetags = "szhang,hlv,mernst,mernst-Testing,plse,plse-testing",
  summary =
   "When a UI changes, a user's workflow must also change.  The FlowFixer
    tool automatically translates an old workflow into one that works on the
    new UI.",
}


@InProceedings{MusluBEN2013,
  author = 	 "K{\i}van{\c{c}} Mu{\c{s}}lu and Yuriy Brun and Michael D. Ernst and David Notkin",
  authorASCII =  "Kivanc Muslu and Yuriy Brun and Michael D. Ernst and David Notkin",
  title = 	 "Making offline analyses continuous",
  crossref =     "FSE2013",
  pages = 	 "323--333",
  abstract =
   "It is beneficial for a developer to know whether a code change affects the
    results of some analysis. Often, the developer must explicitly run each
    analysis.  This interrupts the developer's workflow and/or lengthens the
    delay between the time when the developer makes a change and when the
    developer learns its effects and implications. The situation is even worse
    for an impure analysis --- one that modifies the code on which it runs ---
    because such an analysis blocks the developer from working on the code.
    \par
    This paper presents a novel approach to easily converting an offline
    analysis --- even an impure one --- into a continuous analysis that informs
    the developer of the implications of recent changes as quickly as possible
    after the change is made. Our approach copies the developer's codebase,
    incrementally keeps this codebase in sync with the developer's copy, and
    makes that copy available for offline analyses to run without disturbing
    the developer, and without the developer's changes disturbing the analyses.
    \par
    We have implemented our approach in Solstice, an open-source,
    publicly-available Eclipse plug-in for implementing continuous analyses.
    We used Solstice to convert three offline analyses --- FindBugs, PMD, and
    unit testing --- into continuous ones. Each conversion required only 700
    LoC (600 LoC NCSL) and took, on aver- age, 18 hours by a single developer
    (who was experienced in using Solstice). Solstice-based analyses experience
    under 3 milliseconds in runtime overhead per developer action, which is
    negligible in practice.",
  basefilename = "offline-continuous-esecfse2013",
  downloads =
   "https://bitbucket.org/kivancmuslu/solstice/ Solstice implementation",
  supersededby = "MusluBEN2015",
  category = "Speculative analysis",
  csetags = "kivanc,brun,notkin,mernst,mernst-Software-engineering,plse,plse-speculation",
  summary =
   "An offline program analysis runs when the developer invokes it.  A
    continuous analysis operates automatically on the current codebase and
    asynchronously informs the developer of results.  By using a shadow copy of
    the codebase, an offline analysis can be made continuous.",
}




@InProceedings{BurgBKE2013,
  author = 	 "Brian Burg and Richard Bailey and Andrew J. Ko and Michael D. Ernst",
  title = 	 "Interactive record/replay for web application debugging",
  crossref =     "UIST2013",
  pages = 	 "473--484",
  abstract =
   "During debugging, a developer must repeatedly and manually reproduce faulty
    behaviors in order to inspect different facets of the program's execution.
    Existing tools for reproducing such behaviors prevent the use of debugging
    aids such as breakpoints and logging, and are not designed for interactive,
    random-access exploration of recorded behavior.  This paper presents
    Timelapse, a tool for quickly recording, reproducing, and debugging
    interactive behaviors in web applications.  Developers can use Timelapse to
    browse, visualize, and seek within recorded program executions while
    simultaneously using familiar debugging tools such as breakpoints and
    logging.  Testers and end-users can use Timelapse to demonstrate failures
    \textit{in situ} and share recorded behaviors with developers, improving
    bug report quality by obviating the need for detailed reproduction steps.
    Timelapse is built on Dolos, a novel record/replay infrastructure that
    ensures deterministic execution by capturing and reusing program inputs
    both from the user and from external sources such as the network.  Dolos
    introduces negligible overhead and does not interfere with breakpoints and
    logging.  In a small user evaluation, participants used Timelapse to
    accelerate existing reproduction activities, but were not significantly
    faster or more successful in completing the larger tasks at hand.
    Together, the Dolos infrastructure and Timelapse developer tool support
    systematic bug reporting and debugging practices.",
  basefilename = "record-replay-uist2013",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/record-replay-uist2013.pdf PDF;
    https://homes.cs.washington.edu/~mernst/pubs/record-replay-uist2013-slides.pdf slides (PDF)",
  downloads =
   "https://github.com/burg/replay-staging/ Timelapse implementation",
  category = "Debugging,User interfaces",
  csetags = "burg,rjacob,ajko,mernst,mernst-Software-engineering,plse",
  summary =
   "This paper presents a record-replay infrastructure for web applications.
    It features lightweight recording, and its replay is compatible with
    debuggers and logging.  This enables new developer debugging tools.",
  undergradCoauthor = 1,
}


@Article{BrunHEN2013,
  author = 	 "Yuriy Brun and Reid Holmes and Michael D. Ernst and David Notkin",
  title = 	 "Early detection of collaboration conflicts and risks",
  journal = 	 tse,
  year = 	 2013,
  volume = 	 39,
  number = 	 10,
  pages = 	 "1358--1375",
  month = 	 oct,
  abstract =
   "Conflicts among developers' inconsistent copies of a shared project arise
    in collaborative development and can slow progress and decrease
    quality. Identifying and resolving such conflicts early can
    help. Identifying situations which may lead to conflicts can prevent some
    conflicts altogether. By studying nine open-source systems totaling 3.4
    million lines of code, we establish that conflicts are frequent,
    persistent, and appear not only as overlapping textual edits but also as
    subsequent build and test failures.  Motivated by this finding, we develop
    a speculative analysis technique that uses previously unexploited
    information from version control operations to precisely diagnose important
    classes of conflicts. Then, we design and implement Crystal, a publicly
    available tool that helps developers identify, manage, and prevent
    conflicts. Crystal uses speculative analysis to make concrete advice
    unobtrusively available to developers.",
  basefilename = "vc-conflicts-tse2013",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/vc-conflicts-tse2013.pdf PDF",
  downloads =
   "https://homes.cs.washington.edu/~mernst/pubs/vc-conflicts-fse2011-slides.pdf ESEC/FSE 2011 slides (PDF);
    https://homes.cs.washington.edu/~mernst/pubs/vc-conflicts-fse2011-tooldemo.pdf tool demo paper (PDF);
    https://github.com/brunyuriy/crystalvc Crystal implementation",
  category = "Speculative analysis",
  csetags = "brun,mernst,notkin,mernst-Software-engineering,plse",
  summary =
   "The Crystal tool informs a developer when his individual work can be
    safely merged with his co-workers' changes, and when his individual work
    conflicts with co-workers, by speculatively performing version control
    system operations in the background.",
}



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%% 2014
%%%

@Misc{JSR308-PFD,
  author = 	 "{JSR 308 Expert Group}",
  pseudoauthor = "Michael D. Ernst",
  title = 	 "Annotations on {Java} types",
  howpublished = "\url{https://download.oracle.com/otndocs/jcp/annotations-2014_01_08-pfd-spec/}",
  month = 	 jan # "~8,",
  year = 	 2014,
  note = 	 "Proposed Final Draft.",
  NOabstract =   1,
  basefilename = "annotations-jsr308-pfd",
  downloadsnonlocal = "https://download.oracle.com/otndocs/jcp/annotations-2014_01_08-pfd-spec/ PDF",
  category = "Programming language design",
  csetags = "mernst,mernst-Programming-language-design,plse",
  summary =
   "This specification extends Java's annotation system to permit annotations
    on any use of a type (including generic type arguments, method receivers,
    etc.).  This is the Proposed Final Draft, which is included in Java 8.",
}


@TechReport{ZhangJWMLEN2014:TR,
  author = 	 "Sai Zhang and Darioush Jalali and Jochen Wuttke and K{\i}van{\c{c}} Mu{\c{s}}lu and Wing Lam and Michael D. Ernst and David Notkin",
  authorASCII = 	 "Sai Zhang and Darioush Jalali and Jochen Wuttke and Kivanc Muslu and Wing Lam and Michael D. Ernst and David Notkin",
  title = 	 "Empirically revisiting the test independence assumption",
  institution =  UWCSEDept,
  year = 	 2014,
  number = 	 "UW-CSE-14-01-01",
  address = 	 UWCSEaddr,
  month = 	 jan,
  abstract =
   "In a test suite, all the test cases should be independent:  no test should
    affect any other test's result, and running the tests in any order should
    produce the same test results.  Test independence is important so that
    tests behave consistently as intended by the developers.  In addition,
    techniques such as test prioritization assume that the tests in a suite are
    independent, but they do not justify that assumption.  Test dependence is a
    little-studied phenomenon.  This paper presents five results related to
    test dependence.
    \par
    First, we characterize the test dependence that arises in practice.  We
    studied 96 real-world dependent tests from 5 issue tracking systems.  Our
    study shows that test dependence can be hard for programmers to identify.
    It also shows that test dependence can cause non-trivial consequences, such
    as masking program faults and leading to spurious bug reports.
    \par
    Second, we formally define test dependence in terms of test suites as
    ordered sequences of tests along with explicit environments in which these
    tests are executed.  We formulate the problem of detecting dependent tests
    and prove that a useful special case is NP-complete.
    \par
    Third, guided by the study of real-world dependent tests, we propose and
    compare three algorithms to detect dependent tests in a test suite.
    \par
    Fourth, we applied our dependent test detection algorithms to 4 real-world
    programs and found dependent tests in each human-written and
    automatically-generated test suite.
    \par
    Fifth, we empirically assessed the impact of dependent tests on five test
    prioritization techniques and found that dependent tests affect the output
    of \textit{all} five techniques.",
  basefilename = "test-independence-tr140101",
  downloadsnonlocal = "ftp://ftp.cs.washington.edu/tr/2014/01/UW-CSE-14-01-01.PDF PDF",
  supersededby = "ZhangJWMLEN2014",
  category = "Testing",
  csetags = "mernst,mernst-Testing,plse,plse-testing,szhang,darioush,kivanc",
  summary =
   "A test is indepent if its result does not depend on which other tests have
    been run.  Test prioritizaton and selection assume test independence.  We
    show that both human-written and automatically-generated test suites
    violate the standard test independence assumption.",
  undergradCoauthor = 1,
}


@TechReport{JustJIEHF2014:TR,
  author = 	 "Ren\'e Just and Darioush Jalali and Laura Inozemtseva and Michael D. Ernst and Reid Holmes and Gordon Fraser",
  authorASCII = 	 "Rene Just and Darioush Jalali and Laura Inozemtseva and Michael D. Ernst and Reid Holmes and Gordon Fraser",
  title = 	 "Are mutants a valid substitute for real faults in software testing?",
  institution =  UWCSEDept,
  year = 	 2014,
  number = 	 "UW-CSE-14-02-02",
  address = 	 UWCSEaddr,
  month = 	 mar,
  abstract =
   "A good test suite is one that detects real faults. Because the set of
    faults in a program is unknowable, this definition is not useful to
    practitioners who are creating test suites nor to researchers who are
    creating and evaluating tools that generate test suites. In place of real
    faults, testing research often uses mutants, which are artificial faults
    --- each one a simple syntactic variation --- that are systematically
    seeded throughout the program under test. Mutation testing is appealing
    because large numbers of mutants can be automatically generated and used as
    a proxy for real faults.
    \par
    Unfortunately, there is little experimental evidence to support the use of
    mutants as a proxy for real faults. This paper investigates whether mutants
    are indeed a valid substitute for real faults --- that is, whether a test
    suite's ability to detect mutants is correlated with its ability to detect
    real faults that developers have fixed.
    \par
    Our experiments used 357 real faults in 5 open-source applications
    totalling 321,000 lines of source code. Furthermore, our experiments used
    both developer-written and generated test suites.  We found a statistically
    significant correlation between mutant detection and real fault detection,
    even when controlling for code coverage.",
  supersededby = "JustJIEHF2014",
  basefilename = "mutation-effectiveness-tr20140202",
  category = "Testing",
  csetags = 	 "rjust,darioush,mernst,mernst-Testing,plse,plse-testing",
  summary =
   "Much research in software testing uses mutants (artificial defects) in
   place of real ones.  We investigate whether this assumption is warranted.",
}


@TechReport{BeschastnikhBEK2014:TR,
  author = 	 "Ivan Beschastnikh and Yuriy Brun and Michael D. Ernst and Arvind Krishnamurthy",
  title = 	 "Inferring models of concurrent systems from logs of their behavior with {CSight}",
  institution =  UBC,
  type = 	 "cIRcle: UBC's Digital Repository",
  year = 	 2014,
  address = 	 UBCCSaddr,
  month = 	 feb # "~28,",
  note = 	 "\url{https://hdl.handle.net/2429/46122}",
  abstract =
   "Concurrent systems are notoriously difficult to debug and understand.  A
    common way of gaining insight into system behavior is to inspect execution
    logs and documentation. Unfortunately, manual inspection of logs is an
    arduous process, and documentation is often incomplete and out of sync with
    the implementation.
    \par
    To provide developers with more insight into concurrent systems, we
    developed CSight. CSight mines logs of a system's executions to infer a
    concise and accurate model of that system's behavior, in the form of a
    communicating finite state machine (CFSM).
    \par
    Engineers can use the inferred CFSM model to understand complex behavior,
    detect anomalies, debug, and increase confidence in the correctness of
    their implementations. CSight's only requirement is that the logged events
    have vector timestamps. We provide a tool that automatically adds vector
    timestamps to system logs. Our tool prototypes are available at
    \url{https://github.com/ModelInference/synoptic}.
    \par
    This paper presents algorithms for inferring CFSM models from traces of
    concurrent systems, proves them correct, provides an implementation, and
    evaluates the implementation in two ways: by running it on logs from three
    different networked systems and via a user study that focused on bug
    finding. Our evaluation finds that CSight infers accurate models that can
    help developers find bugs.",
  basefilename = "concurrent-models-tr20140228",
  downloads =
    "https://github.com/ModelInference/synoptic CSight implementation",
  supersededby = "BeschastnikhBEK2014",
  category = "Concurrency,Specification inference",
  csetags = "ivanb,brun,mernst,arvind,mernst-Software-engineering,proj-synoptic,plse",
  summary =
   "This paper provides a new approach to inferring a communicating finite state
    machine (CFSM) from executions of a concurrent system.  The paper also proves
    its techniques correct and evaluates an implementation on system logs and a
    user study.",
}


@InProceedings{AndersonEOPW2014,
  author = 	 "Ruth Anderson and Michael D. Ernst and Robert Ord{\'o}{\~n}ez and Paul Pham and Steven A. Wolfman",
  title = 	 "Introductory programming meets the real world: Using real problems and data in {CS1}",
  crossref =     "SIGCSE2014",
  pages = 	 "465--466",
  abstract =
   "Too many students in introductory programming classes fail to understand
    the significance and utility of the concepts being taught.  Their low
    motivation impacts their learning.  One contributing factor is
    pedagogy that emphasizes computing for its own sake and assignments that
    are abstract, such as computing the factorial function.
    \par
    Many educators have improved on such traditional approaches by teaching
    concepts in contexts that students find more relevant, such as games,
    robots, and media.  Now, it is time to take the next step.
    \par
    In this special session, participants will develop and discuss ways to
    teach introductory programming by means of real-world data analysis
    problems from science, engineering, business, and the humanities.  Students
    can be motivated to learn programming in order to analyze DNA, predict the
    outcome of elections, detect fraudulent data, suggest friends in a social
    network, determine the authorship of texts, and more (see
    Section~3.4 for more examples).  The approach is
    more than just a collection of ``nifty assignments'':  rather, it affects
    the choice of topics and pedagogy, all of which together lead to greater
    student satisfaction.
    \par
    The approach has been successfully used at 4 colleges and universities.
    The classes were effective for both CS and non-CS majors.  Neither the
    computing material nor the problems need to be ``dumbed down''.  At the end
    of the term students were amazed and delighted at the real data analysis
    that they could perform.  They were excited about applying computation in
    their work and about learning more.
    \par
    The special session contains a mix of activities, including comparative
    analysis of introductory classes; group discussion of curriculum design; a
    mini-panel discussing how the approach has worked in practice; and
    brainstorming about example assignments and curriculum revision.",
  basefilename = "data-programming-sigcse2014",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/data-programming-sigcse2014.pdf PDF",
  downloads =
   "https://homes.cs.washington.edu/~mernst/teaching/data-programming/ Data Programming class at UW",
  category = "Education",
  csetags = 	 "rea,mernst,mernst-Software-engineering,plse",
  summary =
   "Most introductory programming classes base their examples and assignments
    on puzzles, games, and abstract math.  We describe an approach that engages
    a different type of student.  Each assignment uses a real-world dataset
    and answers a real question from science, engineering, business, etc."
}


@InProceedings{BhoraskarLHE2014,
  author = 	 "Ravi Bhoraskar and Dominic Langenegger and Pingyang He and Michael D. Ernst",
  title = 	 "User scripting on {Android} using {BladeDroid}",
  crossref =     "NSDI2014",
  abstract =
   "User scripts allow users to customize their app use experience. In web
    apps, for instance, a user may use Greasemonkey scripts and browser
    extensions, to customize the layout of a page, automate repeated tasks,
    block ads, and so on. We bring user-side programmability to mobile
    applications. Using our tool, BladeDroid, users can write scripts that
    enable them to customize their experience within Android apps.
    \par
    We motivate our work using three example applications that can be built
    using BladeDroid --- an Ad Blocker, a Social Media plugin, and a Runtime
    Testing harness. We describe the design and implementation of BladeDroid,
    and propose evaluation metrics to measure its usability, robustness and
    performance.",
  basefilename = "bladedroid-nsdi2014",
  supersededby = "BhoraskarLHCSE2014 A poster",
  category = "Software engineering,User interfaces,Mobile applications",
  csetags = "bhora,pingyh,mernst,mernst-Software-engineering,plse",
  summary =
   "User scripting is common on the Web, but unknown for mobile applications.
    Our BladeDroid system enables users to add scripts to mobile apps.
    The implementation uses bytecode rewriting and dynamic class loading.",
  undergradCoauthor = 1,
}




@TechReport{ErnstJMDPRKBBHVW2014:TR,
  author = 	 "Michael D. Ernst and Ren{\'e} Just and Suzanne Millstein and Werner M. Dietl and Stuart Pernsteiner and Franziska Roesner and Karl Koscher and Paulo Barros and Ravi Bhoraskar and Seungyeop Han and Paul Vines and Edward X. Wu",
  authorASCII = 	 "Michael D. Ernst and Rene Just and Suzanne Millstein and Werner M. Dietl and Stuart Pernsteiner and Franziska Roesner and Karl Koscher and Paulo Barros and Ravi Bhoraskar and Seungyeop Han and Paul Vines and Edward X. Wu",
  title = 	 "Collaborative verification of information flow for a high-assurance app store",
  institution =  UWCSEDept,
  year = 	 2014,
  number = 	 "UW-CSE-14-04-02",
  address = 	 UWCSEaddr,
  month = 	 apr,
  NEEDabstract =  "*",
  basefilename = "infoflow-tr140402",
  OPTdownloads = "",
  OPTdownloadsnonlocal = "",
  supersededby = "ErnstJMDPRKBBHVW2014",
  category = "Security,Verification",
  NEEDcsetags = 	 "*",
  summary =
   "This paper presents a practical, context-sensitive, flow-sensitive type
    system that verifies that an app satisfies an information flow policy.
    The system was effective in an adversarial Red Team evaluation.",
  undergradCoauthor = 1,
}


@InProceedings{BeschastnikhBEK2014,
  author = 	 "Ivan Beschastnikh and Yuriy Brun and Michael D. Ernst and Arvind Krishnamurthy",
  title = 	 "Inferring models of concurrent systems from logs of their behavior with {CSight}",
  crossref =     "ICSE2014",
  pages = 	 "468--479",
  abstract =
   "Concurrent systems are notoriously difficult to debug and understand. A
    common way of gaining insight into system behavior is to inspect execution
    logs and documentation. Unfortunately, manual inspection of logs is an
    arduous process, and documentation is often incomplete and out of sync
    with the implementation.
    \par
    To provide developers with more insight into concurrent systems, we
    developed CSight.  CSight mines logs of a system's executions to infer a
    concise and accurate model of that system's behavior, in the form of a
    communicating finite state machine (CFSM).
    \par
    Engineers can use the inferred CFSM model to understand complex behavior,
    detect anomalies, debug, and increase confidence in the correctness of
    their implementations.  CSight's only requirement is that the logged events
    have vector timestamps.  We provide a tool that automatically adds vector
    timestamps to system logs.  Our tool prototypes are available at
    \url{https://github.com/ModelInference/synoptic}.
    \par
    This paper presents algorithms for inferring CFSM models from traces
    of concurrent systems, proves them correct, provides an
    implementation, and evaluates the implementation in two ways: by
    running it on logs from three different networked systems and via a
    user study that focused on bug finding. Our evaluation finds that
    CSight infers accurate models that can help developers find bugs.",
  basefilename = "concurrent-models-icse2014",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/concurrent-models-icse2014.pdf PDF;
    https://homes.cs.washington.edu/~mernst/pubs/concurrent-models-icse2014-slides.pdf slides (PDF)",
  downloads =
    "https://github.com/ModelInference/synoptic CSight implementation",
  category = "Concurrency,Specification inference",
  csetags = "ivanb,brun,mernst,arvind,mernst-Software-engineering,proj-synoptic,plse",
  summary =
   "This paper provides a new approach to inferring a communicating finite state
    machine (CFSM) from executions of a concurrent system.  The paper also proves
    its techniques correct and evaluates an implementation on system logs and a
    user study.",
}



@InProceedings{ZhangE2014,
  author = 	 "Sai Zhang and Michael D. Ernst",
  title = 	 "Which configuration option should {I} change?",
  crossref =     "ICSE2014",
  pages = 	 "152--163",
  abstract =
   "Modern software often exposes configuration options that enable users to
    customize its behavior. During software evolution,
    developers may change how the configuration options behave.
    When upgrading to a new software version,
    users may need to re-configure the software
    by changing the values of certain configuration options.
    \par
    This paper addresses the following question during the evolution
    of a configurable software system: which configuration options
    should a user change to maintain the software's desired behavior?
    This paper presents a technique (and its tool implementation,
    called ConfSuggester) to troubleshoot configuration errors
    caused by software evolution.
    ConfSuggester uses dynamic profiling, execution trace
    comparison, and static analysis to link the undesired
    behavior to its root cause --- a configuration option
    whose value can be changed to produce desired behavior from the new
    software version.
    \par
    We evaluated ConfSuggester on 8 configuration errors
    from 6 configurable software systems written in Java.
    For 6 errors, the root-cause configuration option was
    ConfSuggester's first suggestion. For 1 error, the root cause
    was ConfSuggester's third suggestion. The root cause
    of the remaining error was ConfSuggester's sixth suggestion.
    Overall, ConfSuggester produced significantly better results
    than two existing techniques. ConfSuggester runs in just a few
    minutes, making it an attractive alternative to manual debugging.",
  basefilename = "confsuggester-icse2014",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/confsuggester-icse2014.pdf PDF;
    https://homes.cs.washington.edu/~mernst/pubs/confsuggester-icse2014-slides.pdf slides (PDF)",
  downloads = "https://github.com/zhang-sai/config-errors ConfSuggester implementation",
  NEEDdownloadsnonlocal = "*",
  category = "Debugging",
  csetags = "mernst,mernst-Testing,plse,plse-testing,szhang",
  summary =
   "A new version of a system may require different configuration options than a
    previous version did.  This paper gives an automated technique for suggesting
    which configuration options to change.  It outperforms previous approaches.",
}


@InProceedings{SchillerDCE2014,
  author = 	 "Todd W. Schiller and Kellen Donohue and Forrest Coward and Michael D. Ernst",
  title = 	 "Case studies and tools for contract specifications",
  crossref =     "ICSE2014",
  pages = 	 "596--607",
  abstract =
   "Contracts are a popular tool for specifying the functional behavior of
    software.
    This paper characterizes the contracts that developers write, the
    contracts that developers could write, and how a developer reacts when
    shown the difference.
    \par
    This paper makes three research contributions based on an
    investigation of open-source projects' use of Code Contracts.
    First, we characterize Code Contract usage in practice.
    For example, approximately three-fourths of the Code Contracts
    are basic checks for the presence of data.  We discuss similarities and
    differences in usage across the projects, and we identify annotation burden,
    tool support, and training as possible explanations based on
    developer interviews.
    Second, based on contracts automatically inferred for four of the projects,
    we find that developers
    underutilize contracts for expressing state updates, object state
    indicators, and conditional properties.
    Third, we performed user studies to learn how developers decide which
    contracts to enforce.  The developers used contract suggestions to support
    their existing use cases with more expressive contracts.  However, the
    suggestions did not lead them to experiment with other use cases for
    which contracts are better-suited.
    \par
    In support of the research contributions, the paper presents two engineering
    contributions:
    (1) Celeriac, a tool for generating traces of .NET
    programs compatible with the Daikon invariant detection tool, and
    (2) Contract Inserter, a Visual Studio add-in for discovering and
    inserting likely invariants as Code Contracts.",
  basefilename = "contract-specifications-icse2014",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/contract-specifications-icse2014.pdf PDF;
    https://homes.cs.washington.edu/~mernst/pubs/contract-specifications-icse2014-slides.pdf slides (PDF)",
  downloads = "https://plse.cs.washington.edu/code-contracts/ data
  and tools",
  category = "Specification inference,Verification",
  csetags = "tws,mernst,mernst-Software-engineering,plse,proj-daikon",
  summary =
   "How do developers use Code Contracts in practice?  How does developers' use
    of Code Contracts compare to true contracts that they could have written?
    How do developers react when shown the difference?  This paper answers these
    questions.",
  undergradCoauthor = 1,
}


@InProceedings{AbrahamsonBBE2014,
  author = 	 "Jenny Abrahamson and Ivan Beschastnikh and Yuriy Brun and Michael D. Ernst",
  title = 	 "Shedding light on distributed system executions",
  crossref =     "ICSE2014",
  pages = 	 "598--599",
  abstract =
   "In a distributed system, the hosts execute concurrently, generating
    asynchronous logs that are challenging to comprehend. We present two tools:
    ShiVector to transparently add vector timestamps to distributed system
    logs, and ShiViz to help developers understand distributed system logs by
    visualizing them as space-time diagrams.  ShiVector is the first tool to
    offer automated vector timestamp instrumentation without modifying source
    code. The vector-timestamped logs capture partial ordering information,
    useful for analysis and comprehension. ShiViz space-time diagrams are
    simple to understand and interactive --- the user can explore the log
    through the visualization to understand complex system behavior. We applied
    ShiVector and ShiViz to two systems and found that they aid developers in
    understanding and debugging.",
  basefilename = "shivector-shiviz-icse2014",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/shivector-shiviz-icse2014.pdf PDF",
  downloads =
   "https://bestchai.bitbucket.io/shiviz/ online deployment (try it!);
    https://github.com/DistributedClocks/shiviz ShiVector and ShiViz source code;
    https://bestchai.bitbucket.io/shiviz-demo/ video demo (YouTube)",
  category = "Distributed systems",
  csetags = "ivanb,brun,mernst,mernst-Distributed-systems,proj-synoptic,plse",
  summary =
   "This paper presents two dools to help developers comprehend distributed
    systems:  ShiVector to add vector timestamps to distributed system logs
    and ShiViz to visualize such logs as space-time diagrams.",
  undergradCoauthor = 1,
}


@InProceedings{BhoraskarLHCSE2014,
  author = 	 "Ravi Bhoraskar and Dominic Langenegger and Pingyang He and Raymond Cheng and Will Scott and Michael D. Ernst",
  title = 	 "User scripting on {Android} using {BladeDroid}",
  crossref =     "APSys2014",
  pages = 	 "9:1--9:7",
  abstract =
   "Compared to desktop and web applications, mobile applications have so far
    been developed in an extremely siloed environment. The apps running on our
    phone are developed by a single entity with operating system protections
    between sharing of data or code between programs.  However, application
    extensibility is often desired.  In the web, a secondary ecosystem
    flourishes around browser extensions, enabling users to customize the web
    as they wish.  This paper presents BladeDroid, a system enabling user
    customization of mobile applications, using a novel combination of bytecode
    rewriting and dynamic class loading. We describe four extensions that we
    have built to evaluate BladeDroid's usability, robustness, and performance.",
  basefilename = "bladedroid-apsys2014",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/bladedroid-apsys2014.pdf PDF",
  category = "User interfaces,Mobile applications",
  csetags = "bhora, dola,pingyh,ryscheng,wrs,mernst,mernst-Software-engineering,plse",
  summary =
   "User scripting is common on the Web, but unknown for mobile applications.
    Our BladeDroid system enables users to add scripts to mobile apps.
    The implementation uses bytecode rewriting and dynamic class loading.",
  undergradCoauthor = 1,
}


@InProceedings{ZhangJWMLEN2014,
  author = 	 "Sai Zhang and Darioush Jalali and Jochen Wuttke and K{\i}van{\c{c}} Mu{\c{s}}lu and Wing Lam and Michael D. Ernst and David Notkin",
  authorASCII = 	 "Sai Zhang and Darioush Jalali and Jochen Wuttke and Kivanc Muslu and Wing Lam and Michael D. Ernst and David Notkin",
  title = 	 "Empirically revisiting the test independence assumption",
  crossref =     "ISSTA2014",
  pages = 	 "385--396",
  abstract =
   "In a test suite, all the test cases should be independent:  no test should
    affect any other test's result, and running the tests in any order should
    produce the same test results.  Techniques such as test prioritization
    generally assume that the tests in a suite are independent.  Test
    dependence is a little-studied phenomenon.  This paper presents five
    results related to test dependence.
    \par
    First, we characterize the test dependence that arises in practice.  We
    studied 96 real-world dependent tests from 5 issue tracking systems.  Our
    study shows that test dependence can be hard for programmers to identify.
    It also shows that test dependence can cause non-trivial consequences,
    such as masking program faults and leading to spurious bug reports.
    \par
    Second, we formally define test dependence in terms of test suites as
    ordered sequences of tests along with explicit environments in which these
    tests are executed.  We formulate the problem of detecting dependent tests
    and prove that a useful special case is NP-complete.
    \par
    Third, guided by the study of real-world dependent tests, we propose and
    compare four algorithms to detect dependent tests in a test suite.
    \par
    Fourth, we applied our dependent test detection algorithms to 4
    real-world programs and found dependent tests in each human-written and
    automatically-generated test suite.
    \par
    Fifth, we empirically assessed the impact of dependent tests on five test
    prioritization techniques.  Dependent tests affect the output of all five
    techniques; that is, the reordered suite fails even though the original
    suite did not.",
  basefilename = "test-independence-issta2014",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/test-independence-issta2014.pdf PDF",
  OLDdownloads = "https://github.com/winglam/dtdetector DTDetector implementation",
  category = "Testing",
  csetags = "mernst,mernst-Testing,plse,plse-testing,szhang,darioush,kivanc",
  summary =
   "A test is indepent if its result does not depend on what other tests have
    been run.  Test prioritizaton and selection assume test independence.  We
    show that both human-written and automatically-generated test suites
    violate the standard test independence assumption.",
  undergradCoauthor = 1,
}


@InProceedings{WeitzKSE2014,
  author = 	 "Konstantin Weitz and Gene Kim and Siwakorn Srisakaokul and Michael D. Ernst",
  title = 	 "A type system for format strings",
  crossref =     "ISSTA2014",
  pages = 	 "127--137",
  abstract =
   "Most programming languages support format strings, but their use is
    error-prone.  Using the wrong format string syntax, or passing the wrong
    number or type of arguments, leads to unintelligible text output, program
    crashes, or security vulnerabilities.
    \par
    This paper presents a type system that guarantees that calls to format
    string APIs will never fail.  In Java, this means that the API will not
    throw exceptions.  In C, this means that the API will not return negative
    values, corrupt memory, etc.
    \par
    We instantiated this type system for Java's Formatter API, and evaluated it
    on 6 large and well-maintained open-source projects.  Format string bugs
    are common in practice (our type system found 104 bugs), and the annotation
    burden on the user of our type system is low (on average, for every bug
    found, only 1.0 annotations need to be written).",
  basefilename = "format-string-issta2014",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/format-string-issta2014.pdf PDF;
    https://homes.cs.washington.edu/~mernst/pubs/format-string-issta2014-slides.pdf slides (PDF)",
  downloads =
   "https://homes.cs.washington.edu/~mernst/pubs/format-string-issta2014-demo.pdf demo paper (PDF);
    https://checkerframework.org/manual/#formatter-checker Format String Checker implementation",
  category = "Verification",
  csetags = "mernst,mernst-Static-Analysis,plse,weitzkon",
  summary =
   "This paper presents a type system that guarantees that invocations of
    format routines, such as printf, will not fail:  the format string is
    well-formed and the arguments are compatible with the format string.",
  undergradCoauthor = 1,
}



@InProceedings{WeitzKSE2014:demo,
  author = 	 "Konstantin Weitz and Gene Kim and Siwakorn Srisakaokul and Michael D. Ernst",
  title = 	 "A format string checker for {Java}",
  crossref =     "ISSTA2014",
  pages = 	 "441--444",
  abstract =
   "Java supports format strings, but their use is error prone because: Java's
    type system does not find any but the most trivial mistakes, Java's format
    methods fail silently, and format methods are often executed infrequently.
    \par
    This paper presents the Format String Checker that is based on the format
    string type system presented in [WeitzKSE2014].  The Format String Checker
    guarantees that calls to Java's Formatter API will not throw exceptions.
    \par
    We evaluate the Format String Checker on 6 large and well-maintained
    open-source projects. Format string bugs are common in practice (we found
    104 bugs), and the annotation burden on the user of our type system is low
    (on average, for every bug found, only 1.0 annotations need to be written).",
  basefilename = "format-string-issta2014demo",
  supersededby = "WeitzKSE2014 A tool demonstration",
  category = "Static analysis",
  csetags = "mernst,mernst-Static-Analysis,plse,weitzkon",
  summary =
   "This tool demo explains how to statically prevent, at compile time,
    errors in usage of format strings.  The Format String Checker is easy to
    use and effective.",
  undergradCoauthor = 1,
}


@InProceedings{JustEF2014,
  author = 	 "Ren\'e Just and Michael D. Ernst and Gordon Fraser",
  authorASCII = 	 "Rene Just and Michael D. Ernst and Gordon Fraser",
  title = 	 "Efficient mutation analysis by propagating and partitioning infected execution states",
  crossref =     "ISSTA2014",
  pages = 	 "315--326",
  abstract =
   "Mutation analysis evaluates a testing technique by measuring how well it
    detects seeded faults (mutants). Mutation analysis is hampered by inherent
    scalability problems --- a test suite is executed for each of a large
    number of mutants.  Despite numerous optimizations presented in the
    literature, this scalability issue remains, and this is one of the reasons
    why mutation analysis is hardly used in practice.
    \par
    Whereas most previous optimizations attempted to statically reduce the
    number of executions or their computational overhead, this paper exploits
    information available only at run time to further reduce the number of
    executions.
    \par
    First, \emph{state infection conditions} can reveal --- with a single test
    execution of the unmutated program --- which mutants would lead to a
    different state, thus avoiding unnecessary test executions.
    Second, determining whether an infected execution state \emph{propagates}
    can further reduce the number of executions. Mutants that are embedded in
    compound expressions may infect the state locally without affecting the
    outcome of the compound expression.
    Third, those mutants that do infect the state can be \emph{partitioned}
    based on the resulting infected state --- if two mutants lead to the same
    infected state, only one needs to be executed as the result of the other
    can be inferred.
    \par
    We have implemented these optimizations in the Major mutation framework and
    empirically evaluated them on 14 open source programs. The optimizations
    reduced the mutation analysis time by 40\% on average.",
  basefilename = "state-infection-issta2014",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/state-infection-issta2014.pdf PDF;
    https://homes.cs.washington.edu/~mernst/pubs/state-infection-issta2014-slides.pdf slides (PDF)",
  downloads = "https://mutation-testing.org/ Major mutation framework and experimental data",
  category = "Testing",
  csetags = "mernst,mernst-Static-Analysis,plse,rjust",
  summary =
   "Mutation analysis --- a technique for evaluating test suites --- is
    notoriously compute-intensive.  This paper reduces its cost by 40\%, by
    running the program being tested a single time in a prepass to determine
    which test results can be predicted and thus do not need to be run.",
}


@InProceedings{JustJE2014,
  author = 	 "Ren{\'e} Just and Darioush Jalali and Michael D. Ernst",
  authorASCII =	 "Rene Just and Darioush Jalali and Michael D. Ernst",
  title = 	 "{Defects4J}: A database of existing faults to enable controlled testing studies for {Java} programs",
  crossref =     "ISSTA2014",
  pages = 	 "437--440",
  note = 	 "Tool demo",
  abstract =
   "Empirical studies in software testing research may not be comparable,
    reproducible, or characteristic of practice.  One reason is that real bugs
    are too infrequently used in software testing research.  Extracting and
    reproducing real bugs is challenging and as a result hand-seeded faults or
    mutants are commonly used as a substitute.
    \par
    This paper presents Defects4J, a database and extensible framework
    providing real bugs to enable reproducible studies in software testing
    research. The initial version of Defects4J contains 357 real bugs from 5
    real-world open source programs. Each real bug is accompanied by a
    comprehensive test suite that can expose (demonstrate) that bug.  Defects4J
    is extensible and builds on top of each program's version control
    system. Once a program is configured in Defects4J, new bugs can be added to
    the database with little or no effort.
    \par
    Defects4J features a framework to easily access faulty and fixed program
    versions and corresponding test suites. This framework also provides a
    high-level interface to common tasks in software testing research, making
    it easy to conduct and reproduce empirical studies.  Defects4J is publicly
    available at \url{https://defects4j.org}.",
  basefilename = "bug-database-issta2014",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/bug-database-issta2014.pdf PDF",
  downloads = "https://defects4j.org/ Defects4J website",
  category = "Software engineering,Testing",
  csetags = "rjust,darioush,mernst,mernst-Static-Analysis,plse",
  summary =
   "Defects4J is a database of real bugs from open source programs.  Each
    bug is isolated and reproducible.  This database enables researchers to
    evaluate their techniques on real-world bugs.",
}


@TechReport{VakilianPEJ2014,
  author = 	 "Vakilian, Mohsen and Phaosawasdi, Amarin and Ernst, Michael D. and Johnson, Ralph E.",
  title = 	 "Cascade: A universal type qualifier inference tool",
  institution =  UIUC,
  year = 	 2014,
  address = 	 UIUCaddr,
  month = 	 sep,
  abstract =
   "Type qualifier inference tools usually operate in batch mode and assume
    that the program must not be changed. In practice, programs must be changed
    to make them type correct, and programmers must understand them. Cascade is
    an interactive type qualifier inference tool that is easy to implement and
    universal (i.e., it can work for any type qualifier system for which a
    checker is implemented). It shows that type qualifier inference can achieve
    better results by reducing the level of automation and involving
    programmers.",
  basefilename = "cascade-typeinference-tr2014",
  downloads =
   "https://www.ideals.illinois.edu/bitstream/handle/2142/54893/2015-icse-tqi.pdf?sequence=2 PDF;
    https://hdl.handle.net/2142/54893 IDEALS permalink",
  supersededby = "VakilianPEJ2015",
  category = "Static analysis",
  csetags = 	 "mernst",
  omitfromcv =   1,
  summary =
   "Rather than operating a type inference tool in batch mode, this paper
    proposes that the tool should be run incrementally, with the programmer
    approving each step and being permitted to edit the program along the way.",
}


@InProceedings{ErnstJMDPRKBBHVW2014,
  author = 	 "Michael D. Ernst and Ren{\'e} Just and Suzanne Millstein and Werner Dietl and Stuart Pernsteiner and Franziska Roesner and Karl Koscher and Paulo Barros and Ravi Bhoraskar and Seungyeop Han and Paul Vines and Edward X. Wu",
  authorASCII = 	 "Michael D. Ernst and Rene Just and Suzanne Millstein and Werner Dietl and Stuart Pernsteiner and Franziska Roesner and Karl Koscher and Paulo Barros and Ravi Bhoraskar and Seungyeop Han and Paul Vines and Edward X. Wu",
  title = 	 "Collaborative verification of information flow for a high-assurance app store",
  crossref =     "CCS2014",
  pages = 	 "1092--1104",
  abstract =
   "Current app stores distribute some malware to unsuspecting users, even
    though the app approval process may be costly and time-consuming.
    High-integrity app stores must provide stronger guarantees that their apps
    are not malicious.  We propose a verification model for use in such app
    stores to guarantee that the apps are free of malicious information flows.
    In our model, the software vendor and the app store auditor collaborate ---
    each does tasks that are easy for her/him, reducing overall verification
    cost.  The software vendor provides a behavioral specification of
    information flow (at a finer granularity than used by current app stores)
    and source code annotated with information-flow type qualifiers.  A
    flow-sensitive, context-sensitive information-flow type system checks the
    information flow type qualifiers in the source code and proves that only
    information flows in the specification can occur at run time.  The app
    store auditor uses the vendor-provided source code to manually verify
    declassifications.
    \par
    We have implemented the information-flow type system for Android apps
    written in Java, and we evaluated both its effectiveness at detecting
    information-flow violations and its usability in practice.  In an
    adversarial Red Team evaluation, we analyzed 72 apps (576,000 LOC) for
    malware.  The 57 Trojans among these had been written specifically to
    defeat a malware analysis such as ours.  Nonetheless, our information-flow
    type system was effective: it detected 96\% of malware whose malicious
    behavior was related to information flow and 82\% of all malware.  In
    addition to the adversarial evaluation, we evaluated the practicality of
    using the collaborative model.  The programmer annotation burden is low: 6
    annotations per 100 LOC\@.  Every sound analysis requires a human to review
    potential false alarms, and in our experiments, this took 30 minutes per
    1,000 LOC for an auditor unfamiliar with the app.",
  basefilename = "infoflow-ccs2014",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/infoflow-ccs2014.pdf PDF;
    https://homes.cs.washington.edu/~mernst/pubs/infoflow-ccs2014-slides.pdf slides (PDF)",
  downloads = "https://types.cs.washington.edu/sparta/ SPARTA toolset and experimental data",
  category = "Security,Verification,Mobile applications",
  csetags = "mernst,rjust,smillst,wmdietl,spernste,franzi,supersat,pbsf,bhora,syhan,plvines,edwardwu,mernst-Security,plse,proj-sparta",
  summary =
   "This paper presents a practical, context-sensitive, flow-sensitive type
    system that verifies that an app satisfies an information flow policy.
    The system was effective in an adversarial Red Team evaluation.",
  undergradCoauthor = 1,
}


@InProceedings{JustJIEHF2014,
  author = 	 "Ren\'e Just and Darioush Jalali and Laura Inozemtseva and Michael D. Ernst and Reid Holmes and Gordon Fraser",
  authorASCII = 	 "Rene Just and Darioush Jalali and Laura Inozemtseva and Michael D. Ernst and Reid Holmes and Gordon Fraser",
  title = 	 "Are mutants a valid substitute for real faults in software testing?",
  crossref =     "FSE2014",
  pages = 	 "654--665",
  abstract =
   "A good test suite is one that detects real faults.  Because the set of
    faults in a program is usually unknowable, this definition is not useful to
    practitioners who are creating test suites, nor to researchers who are
    creating and evaluating tools that generate test suites.  In place of real
    faults, testing research often uses mutants, which are artificial faults
    --- each one a simple syntactic variation --- that are systematically
    seeded throughout the program under test. Mutation analysis is appealing
    because large numbers of mutants can be automatically-generated and used to
    compensate for low quantities or the absence of known real faults.
    \par
    Unfortunately, there is little experimental evidence to support the use of
    mutants as a replacement for real faults.  This paper investigates whether
    mutants are indeed a valid substitute for real faults, i.e., whether a test
    suite's ability to detect mutants is correlated with its ability to detect
    real faults that developers have fixed.  Unlike prior studies, these
    investigations also explicitly consider the conflating effects of code
    coverage on the mutant detection rate.
    \par
    Our experiments used 357 real faults in 5 open-source applications that
    comprise a total of 321,000 lines of code.  Furthermore, our experiments
    used both developer-written and automatically-generated test suites.  The
    results show a statistically significant correlation between mutant
    detection and real fault detection, independently of code coverage.  The
    results also give concrete suggestions on how to improve mutation analysis
    and reveal some inherent limitations.",
  basefilename = "mutation-effectiveness-fse2014",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/mutation-effectiveness-fse2014.pdf PDF;
    https://homes.cs.washington.edu/~mernst/pubs/mutation-effectiveness-fse2014-slides.pdf slides (PDF)",
  downloads =
   "https://defects4j.org/ Defects4J subject programs;
    https://mutation-testing.org/ Major mutation tool",
  category = "Testing",
  csetags = "rjust,darioush,mernst,mernst-Testing,plse",
  summary =
   "Much research in software testing uses mutants (artificial defects) in
   place of real ones.  We investigate whether this assumption is warranted.",
}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%% 2015
%%%

@TechReport{LamZE2015,
  author = 	 "Wing Lam and Sai Zhang and Michael D. Ernst",
  title = 	 "When tests collide: Evaluating and coping with the impact of test dependence",
  institution =  UWCSEDept,
  year = 	 2015,
  number = 	 "UW-CSE-15-03-01",
  address = 	 UWCSEaddr,
  month = 	 mar,
  abstract =
   "In a test suite, all the test cases should be independent: no test should
    affect any other test's result, and running the tests in any order should
    produce the same test results. The assumption of test independence is
    important so that tests behave consistently as designed. In addition, many
    downstream testing techniques, including test prioritization, test
    selection, and test parallelization, assume test independence. However,
    this critical assumption often does not hold in practice.
    \par
    This paper empirically investigates the impact of test dependence on three
    downstream testing techniques (test prioritization, selection, and
    parallelization) and proposes a general approach to cope with such
    impact. It presents two sets of results.
    \par
    First, we describe an empirical study to assess the impact of test
    dependence on 4 test prioritization, 6 test selection, and 2 test
    parallelization algorithms. Test dependence negatively affects the results
    of all these downstream testing algorithms. For example, an
    automatically-generated test suite for the XML-Security program contains
    665 tests, and 111 of those tests yield a different test result (success
    vs. fail) if the suite is parallelized to run on 16 CPUs.
    \par
    Second, we present an approach that enhances each test prioritization,
    selection, and parallelization algorithm to respect test dependence, so
    that each test in a suite yields the same result before and after applying
    the downstream testing technique. In an experimental evaluation, the
    enhanced testing algorithms worked as intended: the test results were
    consistent even in the presence of test dependence, and they did not
    substantially compromise the effectiveness of the original testing
    algorithms.",
  basefilename = "deptest-impact-tr150301",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/deptest-impact-tr150301.pdf PDF",
  TOBEsupersededby = "*",
  category = "Testing",
  csetags = "mernst,mernst-Testing,plse",
  summary =
    "This paper shows that test prioritization, selection, and parallelization
     yield incorrect results (test suites that spuriously fail) for real-world
     test suites, and gives an algorithm that makes those techniques correct.",
}

@InProceedings{AndersonEOPT2015,
  author = 	 "Ruth Anderson and Michael D. Ernst and Robert Ord{\'o}{\~n}ez and Paul Pham and Ben Tribelhorn",
  authorASCII = 	 "Ruth Anderson and Michael D. Ernst and Robert Ordonez and Paul Pham and Ben Tribelhorn",
  title = 	 "A data programming {CS1} course",
  crossref =     "SIGCSE2015",
  pages = 	 "150--155",
  abstract =
   "This paper reports on our experience teaching introductory programming by
    means of real-world data analysis. We have found that students can be
    motivated to learn programming and computer science concepts in order to
    analyze DNA, predict the outcome of elections, detect fraudulent data,
    suggest friends in a social network, determine the authorship of documents,
    and more.  The approach is more than just a collection of ``nifty
    assignments''; rather, it affects the choice of topics and pedagogy.
    \par
    This paper describes how our approach has been used at four diverse
    colleges and universities to teach CS majors and non-majors alike. It
    outlines the types of assignments, which are based on problems from
    science, engineering, business, and the humanities. Finally, it offers
    advice for anyone trying to integrate the approach into their own
    institution.",
  basefilename = "data-programming-sigcse2015",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/data-programming-sigcse2015.pdf PDF",
  downloads =
   "https://homes.cs.washington.edu/~mernst/teaching/data-programming/ Data Programming class at UW",
  category = "Education",
  csetags = 	 "rea,mernst,mernst-Software-engineering,plse",
  summary =
   "This paper describes experience, at 4 colleges and universities, with an
    approach to teaching introductory programming in which each assignment uses
    a real-world dataset and answers a real question from science,
    engineering, business, etc."
}


@Article{BeschastnikhBAEK2015,
  author = 	 "Ivan Beschastnikh and Yuriy Brun and Jenny Abrahamson and Michael D. Ernst and Arvind Krishnamurthy",
  title = 	 "Using declarative specification to improve the understanding, extensibility, and comparison of model-inference algorithms",
  journal = 	 TSE,
  year = 	 2015,
  volume = 	 41,
  number = 	 4,
  pages = 	 "408--428",
  month = 	 apr,
  issn = {0098-5589},
  doi = {10.1109/TSE.2014.2369047},
  abstract =
   "It is a staple development practice to log system behavior.  Numerous
    powerful model-inference algorithms have been proposed to aid developers in
    log analysis and system understanding.  Unfortunately, existing algorithms
    are typically declared \emph{procedurally}, making them difficult to
    understand, extend, and compare. This paper presents InvariMint, an
    approach to specify model-inference algorithms \emph{declaratively}.
    \par
    We applied the InvariMint declarative approach to two model-inference
    algorithms.  The evaluation results illustrate that InvariMint (1)~leads to
    new fundamental insights and better understanding of existing algorithms,
    (2)~simplifies creation of new algorithms, including hybrids that combine
    or extend existing algorithms, and (3)~makes it easy to compare and
    contrast previously published algorithms.
    \par
    InvariMint's declarative approach can outperform procedural
    implementations. For example, on a log of 50,000 events, InvariMint's
    declarative implementation of the kTails algorithm completes in 12 seconds,
    while a procedural implementation completes in 18 minutes.  We also found
    that InvariMint's declarative version of the Synoptic algorithm can be over
    170 times faster than the procedural implementation.",
  basefilename = "fsm-inference-declarative-tse2015",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/fsm-inference-declarative-tse2015.pdf PDF",
  downloads =
   "https://homes.cs.washington.edu/~mernst/pubs/fsm-inference-declarative-icse2013-slides.pdf ICSE 2013 slides (PDF);
    https://github.com/ModelInference/synoptic InvariMint implementation",
  category = "Specification inference",
  csetags = "ivanb,brun,mernst,jabrah,arvind,mernst-Software-engineering,proj-synoptic,plse",
  summary =
   "Model inference algorithms summarize a log to make it easier to understand.
    But the algorithm itself can be hard to understand, especially if specified
    procedurally.  InvariMint gives a declarative and efficient way to specify
    model inference algorithms.",
  undergradCoauthor = 1,
}


@TechReport{BarrosJMVDdAE2015:TR-UW-CSE-15-05-01,
  author = 	 "Paulo Barros and Ren\'e Just and Suzanne Millstein and Paul Vines and Werner Dietl and Marcelo d'Amorim and Michael D. Ernst",
  authorASCII = 	 "Paulo Barros and Rene Just and Suzanne Millstein and Paul Vines and Werner Dietl and Marcelo d'Amorim and Michael D. Ernst",
  title = 	 "Static analysis of implicit control flow: Resolving {Java} reflection and {Android} intents",
  institution =  UWCSEDept,
  year = 	 2015,
  number = 	 "UW-CSE-15-05-01",
  address = 	 UWCSEaddr,
  month = 	 may,
  abstract =
   "Implicit or indirect control flow is a transfer of control between
    procedures using some mechanism other than an explicit procedure call.
    Implicit control flow is a staple design pattern that adds flexibility to
    system design.  However, it is challenging for a static analysis to
    compute or verify properties about a system that uses implicit control
    flow.
    \par
    This paper presents static analyses for two types of implicit control
    flow that frequently appear in Android apps: Java reflection and Android
    intents.  Our analyses help to resolve where control flows and what data
    is passed.  This information improves the precision of downstream
    analyses, which no longer need to make conservative assumptions about
    implicit control flow.
    \par
    We have implemented our techniques for Java.  We enhanced an existing
    security analysis with a more precise treatment of reflection and
    intents.  In a case study involving ten real-world Android apps that use
    both intents and reflection, precision of the security analysis was
    increased on average by two orders of magnitude.",
  basefilename = "implicit-control-flow-tr150801",
  downloads =
   "https://types.cs.washington.edu/sparta/ SPARTA toolset;
    https://checkerframework.org/ Checker Framework",
  supersededby = "BarrosJMVDdAE2015",
  category = "Static analysis,Mobile applications",
  csetags = "rjust,smillst,plvines,wmdietl,mernst,mernst-Static-analysis,plse",
  summary =
   "Standard program analysis understands control flow through direct procedure
    calls.  This paper provides analyses that resolve uses of Java reflecton and
    the data passed in Android intents.",
}


@InProceedings{ErnstGJLPTTW2015,
  author = 	 "Michael D. Ernst and Dan Grossman and Jon Jacky and Calvin Loncaric and Stuart Pernsteiner and Zachary Tatlock and Emina Torlak and Xi Wang",
  title = 	 "Toward a dependability case language and workflow for a radiation therapy system",
  crossref =     "SNAPL2015",
  pages = 	 "103--112",
  abstract =
   "We present a near-future research agenda for bringing a suite of
    modern programming-languages verification tools---specifically
    interactive theorem proving, solver-aided languages, and formally
    defined domain-specific languages---to the development of a specific
    safety-critical system, a radiotherapy medical device.  We sketch how
    we believe recent programming-languages research advances can merge
    with existing best practices for safety-critical systems to increase
    system assurance and developer productivity.  We motivate hypotheses
    central to our agenda: That we should start with a single specific
    system and that we need to integrate a variety of complementary
    verification and synthesis tools into system development.",
  basefilename = "dependability-case-snapl2015",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/dependability-case-snapl2015.pdf PDF;
    https://homes.cs.washington.edu/~mernst/pubs/dependability-case-snapl2015-slides.pdf slides (PDF)",
  category = "Verification",
  csetags = 	 "mernst,djg,loncaric,spernste,ztatlock,emina,xi,mernst-Verification,plse",
  summary =
   "This paper proposes the use of interactive theorem proving, solver-aided
    languages, and formally defined domain-specific languages for the
    development of a safety-critical radiotherapy medical device.",
}


@InProceedings{VakilianPEJ2015,
  author = 	 "Vakilian, Mohsen and Phaosawasdi, Amarin and Ernst, Michael D. and Johnson, Ralph E.",
  title = 	 "Cascade: A universal programmer-assisted type qualifier inference tool",
  crossref =     "ICSE2015",
  pages = 	 "234--245",
  abstract =
   "Type qualifier inference tools usually operate in batch mode and assume
    that the program must not be changed except to add the type qualifiers. In
    practice, programs must be changed to make them type-correct, and
    programmers must understand them. Cascade is an interactive type qualifier
    inference tool that is easy to implement and universal (i.e., it can work
    for any type qualifier system for which a checker is implemented). It shows
    that qualifier inference can achieve better results by involving
    programmers rather than relying solely on automation.",
  basefilename = "cascade-typeinference-icse2015",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/cascade-typeinference-icse2015.pdf PDF;
    https://homes.cs.washington.edu/~mernst/pubs/cascade-typeinference-icse2015-slides.pdf slides (PDF)",
  downloads =
   "https://docs.google.com/presentation/d/1huP5pbe-ohrRSt5ASwsflFJYX0Y877a6VZCwtFHDqgM/ slides (Google Slides);
    https://github.com/reprogrammer/cascade Cascade tool;
    https://github.com/reprogrammer/tqi-study user study materials",
  category = "Static analysis",
  csetags = 	 "mernst",
  summary =
   "Rather than operating a type inference tool in batch mode, this paper
    proposes that the tool should be run incrementally, with the programmer
    approving each step and being permitted to edit the program along the way.",
}


@InProceedings{WilcoxWPTWEA2015,
  author = 	 "James R. Wilcox and Doug Woos and Pavel Panchekha and Zachary Tatlock and Xi Wang and Michael D. Ernst and Thomas Anderson",
  title = 	 "Verdi:  A framework for implementing and formally verifying distributed systems",
  crossref =     "PLDI2015",
  pages = 	 "357--368",
  abstract =
   "Distributed systems are difficult to implement correctly because they
    must handle both concurrency and failures: machines may crash at
    arbitrary points and networks may reorder, drop, or duplicate packets.
    Further, their behavior is often too complex to permit exhaustive
    testing.  Bugs in these systems have led to the loss of critical data and
    unacceptable service outages.
    \par
    We present Verdi, a framework for implementing and formally verifying
    distributed systems in Coq.  Verdi formalizes various network semantics
    with different faults, and the developer chooses the most
    appropriate fault model when verifying their implementation. Furthermore,
    Verdi eases the verification burden by enabling the developer to first verify
    their system under an idealized fault model, then transfer the resulting
    correctness guarantees to a more realistic fault model without any
    additional proof burden.
    \par
    To demonstrate Verdi's utility, we present the first mechanically
    checked proof of linearizability of the Raft state machine
    replication algorithm, as well as verified implementations of a
    primary-backup replication system and a key-value store. These
    verified systems provide similar performance to unverified
    equivalents.",
  basefilename = "verify-distsystem-pldi2015",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/verify-distsystem-pldi2015.pdf PDF",
  downloads =
    "https://verdi.uwplse.org/verdi_slides.pdf slides (PDF);
     https://verdi.uwplse.org/ Verdi website;
     https://github.com/uwplse/verdi Verdi implementation",
  category = "Distributed systems,Verification",
  csetags = 	 "jrw12,dwoos,pavpan,ztatlock,xi,mernst,tom,mernst-Verification,plse",
  summary =
   "This paper presents Verdi, a methodology and toolset for modularly
    implementing and formally verifying practical distributed systems in
    Coq.  Case studies include a key-value store and a primary-backup
    replication mechanism.",
}


@InProceedings{ZhangE2015,
  author = 	 "Sai Zhang and Michael D. Ernst",
  title = 	 "Proactive detection of inadequate diagnostic messages for software configuration errors",
  crossref =     "ISSTA2015",
  pages = 	 "12--23",
  abstract =
   "This paper presents a technique to detect inadequate (i.e., missing or
    ambiguous) diagnostic messages for configuration errors issued by a
    configurable software system.
    \par
    The technique injects configuration errors into the software under test,
    monitors the software outcomes under the injected configuration errors, and
    uses natural language processing to analyze the output diagnostic message
    caused by each configuration error. The technique reports diagnostic
    messages that may be unhelpful in diagnosing a configuration error.
    \par
    We implemented the technique for Java in a tool, ConfDiagDetector. In an
    evaluation on 4 real-world, mature configurable systems, ConfDiagDetector
    reported 43 distinct inadequate diagnostic messages (25 missing and 18
    ambiguous). 30 of the detected messages have been confirmed by their
    developers, and 12 more have been identified as inadequate by users in a
    user study. On average, ConfDiagDetector required 5 minutes of programmer
    time and 3 minutes of compute time to detect each inadequate diagnostic
    message.",
  basefilename = "inadequate-diagnostics-issta2015",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/inadequate-diagnostics-issta2015.pdf PDF;
    https://homes.cs.washington.edu/~mernst/pubs/inadequate-diagnostics-issta2015-slides.pdf slides (PDF)",
  downloads = "https://github.com/zhang-sai/config-errors ConfDiagDetector implementation",
  category = "Defect prediction,Natural language processing",
  csetags = "szhang,mernst,mernst-Natural-language-processing,plse",
  summary =
   "ConfDiagDetector detects inadequate diagnostic messages for configuration
    errors.  It works by injecting misconfigurations and using natural
    language processing to analyze the resulting diagnostic messages.",
}


@InProceedings{DeanGEKPWCMMCM2015,
  author = 	 "Drew Dean and Sean Guarino and Leonard Eusebi and Andrew Keplinger and Tim Pavlik and Ronald Watro and Aaron Cammarata and John Murray and Kelly McLaughlin and John Cheng and Thomas Maddern",
  pseudoauthor = "Michael D. Ernst",
  title = 	 "Lessons learned in game development for crowdsourced software formal verification",
  crossref =     "ThreeGSE2015",
  NOpages = 	 "*",
  abstract =
   "The history of formal methods and computer security research is long and
    intertwined. Program logics that were in theory capable of proving security
    properties of software were developed by the early 1970s. The development
    of the first security models gave rise to a desire to prove that the models
    did, in fact, enforce the properties that they claimed to, and that an
    actual implementation of the model was correct with respect to its
    specification. Optimism reached its peak in the early to mid-1980s, and the
    peak of formal methods for security was reached shortly before the
    publication of the Orange Book, where the certification of a system at
    class A1 required formal methods. Formal verification of software was
    considered the gold standard evidence that the software enforced a
    particular set of properties. Soon afterwards, the costs of formal methods,
    in both time and money, became all too apparent. Mainstream computer
    security research shifted focus to analysis of cryptographic protocols,
    policies around cryptographic key management, and clever fixes for security
    problems found in contemporary systems.",
  basefilename = "csfv-lessons-3gse2015",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/csfv-lessons-3gse2015.pdf PDF",
  OLDdownloads =
   "https://www.cs.washington.edu/verigames/ Verification Games project homepage;
    https://games.cs.washington.edu/verigame/flowjam/ Flow Jam game;
    https://paradox.centerforgamescience.org/paradox/Paradox.html Paradox game",
  category = "Verification",
  csetags = 	 "mernst,mernst-Verification",
  summary =
   "Crowd-sourcing provides the promise of making formal verification cheaper
    and thus more prevalent.  This paper overviews 5 games by which unskilled
    people can perform program verification tasks.",
}


@TechReport{BarrosJMVDdAE2015:TR,
  author = 	 "Paulo Barros and Ren\'e Just and Suzanne Millstein and Paul Vines and Werner Dietl and Marcelo d'Amorim and Michael D. Ernst",
  authorASCII = 	 "Paulo Barros and Rene Just and Suzanne Millstein and Paul Vines and Werner Dietl and Marcelo d'Amorim and Michael D. Ernst",
  title = 	 "Static analysis of implicit control flow: Resolving {Java} reflection and {Android} intents (extended version)",
  institution =  UWCSEDept,
  year = 	 2015,
  number = 	 "UW-CSE-15-08-01",
  address = 	 UWCSEaddr,
  month = 	 aug,
  abstract =
   "Implicit or indirect control flow is a transfer of control between
    procedures using some mechanism other than an explicit procedure call.
    Implicit control flow is a staple design pattern that adds flexibility to
    system design.  However, it is challenging for a static analysis to
    compute or verify properties about a system that uses implicit control
    flow.
    \par
    This paper presents static analyses for two types of implicit control
    flow that frequently appear in Android apps:  Java reflection and Android
    intents.  Our analyses help to resolve where control flows and what data
    is passed.  This information improves the precision of downstream
    analyses, which no longer need to make conservative assumptions about
    implicit control flow.
    \par
    We have implemented our techniques for Java.  We enhanced an existing
    security analysis with a more precise treatment of reflection and
    intents.  In a case study involving ten real-world Android apps that use
    both intents and reflection, the precision of the security analysis was
    increased on average by two orders of magnitude.  The precision of two
    other downstream analyses was also improved.",
  basefilename = "implicit-control-flow-tr150801",
  downloads =
   "https://types.cs.washington.edu/sparta/ SPARTA toolset;
    https://checkerframework.org/ Checker Framework",
  supersededby = "BarrosJMVDdAE2015 An extended version",
  category = "Static analysis,Mobile applications",
  csetags = "rjust,smillst,plvines,wmdietl,mernst,mernst-Static-analysis,plse",
  summary =
   "Standard program analysis understands control flow through direct procedure
    calls.  This paper provides analyses that resolve uses of Java reflecton and
    the data passed in Android intents.",
  undergradCoauthor = 1,
}


@TechReport{ErnstMMS2015,
  author = 	 "Michael D. Ernst and Damiano Macedonio and Massimo Merro and Fausto Spoto",
  title = 	 "Semantics for locking specifications",
  institution =  UWCSEDept,
  year = 	 2015,
  number = 	 "UW-CSE-15-09-01",
  address = 	 UWCSEaddr,
  month = 	 sep,
  abstract =
   "To prevent concurrency errors, programmers need to obey a locking
    discipline.  Annotations that specify that discipline, such as Java's
    \texttt{@GuardedBy}, are already widely used.  Unfortunately, their
    semantics is expressed informally and is consequently ambiguous.  This
    article highlights such ambiguities and overcomes them by formalizing
    two possible semantics of \texttt{@GuardedBy}, using a reference
    operational semantics for a core calculus of a concurrent Java-like
    language.  It also identifies when such annotations are actual
    guarantees against data races.  Our work aids in understanding the
    annotations and supports the development of sound tools that verify or
    infer them.",
  basefilename = "locking-semantics-tr150901",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/locking-semantics-tr150901.pdf PDF",
  supersededby = "ErnstMMS2016",
  category = "Concurrency",
  csetags = "mernst,jthaine,mernst-Static-analysis,plse",
  summary =
   "Java's @GuardedBy annotation is intended to prevent race conditions, but
    current tools give it a definition that permits race conditions.  This paper
    formalizes a correct definition that prevents race conditions as intended.",
}


@TechReport{ErnstLMST2015,
  author = 	 "Michael D. Ernst and Alberto Lovato and Damiano Macedonio and Fausto Spoto and Javier Thaine",
  title = 	 "Locking discipline inference and checking",
  institution =  UWCSEDept,
  year = 	 2015,
  number = 	 "UW-CSE-15-09-02",
  address = 	 UWCSEaddr,
  month = 	 sep,
  abstract =
   "Concurrency is a requirement for much modern software, but the
    implementation of multithreaded algorithms comes at the risk of errors
    such as data races.  Programmers can prevent data races by documenting
    and obeying a locking discipline, which indicates which locks must be
    held in order to access which data.
    \par
    This paper introduces a formal semantics for locking specifications that
    gives a guarantee of race freedom.  The paper also provides two
    implementations of the formal semantics for the Java language:  one based
    on abstract interpretation and one based on type theory.  To the best of
    our knowledge, these are the first tools that can soundly infer and check
    a locking discipline for Java.  Our experiments compare the implementations
    with one another and with annotations written by programmers.",
  basefilename = "locking-inference-checking-tr150902",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/locking-inference-checking-tr150902.pdf PDF",
  supersededby = "ErnstLMST2016",
  category = "Concurrency",
  csetags = "mernst,jthaine,mernst-Static-analysis,plse",
  summary =
   "This paper describes an abstract inference and a type system and for
    inferring and checking a locking discipline, and experiments with
    implementations of each.",
}



@TechReport{ErnstLMSS2015:TR,
  author = 	 "Michael D. Ernst and Alberto Lovato and Damiano Macedonio and Ciprian Spiridon and Fausto Spoto",
  title = 	 "Boolean formulas for the static identification of injection attacks in {Java}",
  institution =  UWCSEDept,
  year = 	 2015,
  number = 	 "UW-CSE-15-09-03",
  address = 	 UWCSEaddr,
  month = 	 sep,
  abstract =
   "The most dangerous security-related software errors, according to CWE 2011,
    are those leading to injection attacks --- user-provided data that result
    in undesired database access and updates (\emph{SQL-injec\-tions}), dynamic
    generation of web pages (\emph{cross-site scripting-injections}),
    redirection to user-specified web pages (\emph{redirect-injections}),
    execution of OS commands (\emph{command-injections}), class loading of
    user-specified classes (\emph{reflection-injections}), and many others.
    This paper describes a flow- and context-sensitive static analysis that
    automatically identifies if and where injections of tainted data can occur
    in a program.  The analysis models explicit flows of tainted data.  Its
    notion of taintedness applies also to reference (non-primitive) types
    dynamically allocated in the heap, and is object-sensitive and
    field-sensitive.  The analysis works by translating the program into
    Boolean formulas that model all possible flows.  We implemented it within
    the Julia analyzer for Java and Android. Julia found injection security
    vulnerabilities in the Internet banking service and in the customer
    relationship management of a large Italian bank.",
  basefilename = "injection-attacks-tr150903",
  supersededby = "ErnstLMSS2015",
  category = "Security,Mobile applications",
  csetags = "mernst,mernst-Static-analysis,plse",
  summary =
   "This paper describes a flow- and context-sensitive static analysis that
    automatically identifies if and where injections of tainted data can occur
    in a program.  The analysis models explicit flows of tainted data.",
}


@InProceedings{UlHaqCE2015,
  author = 	 "Ul Haq, Irfan and Juan Caballero and Michael D. Ernst",
  title = 	 "Ayudante: Identifying undesired variable interactions",
  crossref =     "WODA2015",
  pages = 	 "8--13",
  abstract =
   "A common programming mistake is for incompatible variables to interact,
    e.g., storing euros in a variable that should hold dollars, or using an
    array index with the wrong array.  This paper proposes a novel approach for
    identifying undesired interactions between program variables.  Our approach
    uses two different mechanisms to identify related variables.  Natural
    language processing (NLP) identifies variables with related names that may
    have related semantics.  Abstract type inference (ATI) identifies variables
    that interact with each other.  Any discrepancies between these two
    mechanisms may indicate a programming error.
    \par
    We have implemented our approach in a tool called Ayudante.  We evaluated
    Ayudante using two open-source programs:  the Exim mail server and grep.
    Although these programs have been extensively tested and in deployment for
    years, Ayudante's first report for grep revealed a programming mistake.",
  basefilename = "variable-interactions-woda2015",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/variable-interactions-woda2015.pdf PDF;
    https://homes.cs.washington.edu/~mernst/pubs/variable-interactions-woda2015-slides.pdf slides (PDF)",
  category = "Natural language processing",
  csetags = "mernst,mernst-Natural-language-processing,plse",
  summary =
   "Two different ways of identifying related variables are those that interact
    (such as being involved in the same + operation) and those with similar
    variable names.  When these give different results, it can indicate a bug."
}


@InProceedings{BurgKE2015,
  author = 	 "Brian Burg and Andrew J. Ko and Michael D. Ernst",
  title = 	 "Explaining visual changes in web interfaces",
  crossref =     "UIST2015",
  pages = 	 "259--268",
  abstract =
   "Web developers often want to repurpose interactive behaviors from
    third-party web pages, but struggle to locate the specific source code that
    implements the behavior. This task is challenging because developers must
    find and connect all of the non-local interactions between event-based
    JavaScript code, declarative CSS styles, and web page content that combine
    to express the behavior.
    \par
    The Scry tool embodies a new approach to locating the code that implements
    interactive behaviors.  A developer selects a page element; whenever the
    element changes, Scry captures the rendering engine's inputs (DOM, CSS) and
    outputs (screenshot) for the element. For any two captured element states,
    Scry can compute how the states differ and which lines of JavaScript code
    were responsible. Using Scry, a developer can locate an interactive
    behavior's implementation by picking two output states; Scry indicates the
    JavaScript code directly responsible for their differences.",
  basefilename = "dom-tracing-uist2015",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/dom-tracing-uist2015.pdf PDF;
    https://homes.cs.washington.edu/~mernst/pubs/dom-tracing-uist2015-slides.pdf slides (PDF)",
  downloads =
   "https://github.com/burg/replay-staging/ Timelapse implementation",
  category = "User interfaces",
  csetags = "burg,ajko,mernst,mernst-Software-engineering,plse",
  summary =
   "The Scry tool enables a developer to navigate forward and backward in a web
    page's execution.  When the developer selects a web page element, Scry shows
    how the browser state differed and what JavaScript code is responsible.",
}


@InProceedings{BarrosJMVDdAE2015,
  author = 	 "Paulo Barros and Ren\'e Just and Suzanne Millstein and Paul Vines and Werner Dietl and Marcelo d'Amorim and Michael D. Ernst",
  authorASCII = 	 "Paulo Barros and Rene Just and Suzanne Millstein and Paul Vines and Werner Dietl and Marcelo d'Amorim and Michael D. Ernst",
  title = 	 "Static analysis of implicit control flow: Resolving {Java} reflection and {Android} intents",
  crossref =     "ASE2015",
  pages = 	 "669-679",
  abstract =
   "Implicit or indirect control flow is a transfer of control between
    procedures using some mechanism other than an explicit procedure call.
    Implicit control flow is a staple design pattern that adds flexibility to
    system design.  However, it is challenging for a static analysis to
    compute or verify properties about a system that uses implicit control
    flow.
    \par
    This paper presents static analyses for two types of implicit control
    flow that frequently appear in Android apps:  Java reflection and Android
    intents.  Our analyses help to resolve where control flows and what data
    is passed.  This information improves the precision of downstream
    analyses, which no longer need to make conservative assumptions about
    implicit control flow.
    \par
    We have implemented our techniques for Java.  We enhanced an existing
    security analysis with a more precise treatment of reflection and
    intents.  In a case study involving ten real-world Android apps that use
    both intents and reflection, the precision of the security analysis was
    increased on average by two orders of magnitude.  The precision of two
    other downstream analyses was also improved.",
  basefilename = "implicit-control-flow-ase2015",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/implicit-control-flow-ase2015.pdf PDF;
    https://homes.cs.washington.edu/~mernst/pubs/implicit-control-flow-ase2015-slides.pdf slides (PDF)",
  downloads =
   "https://homes.cs.washington.edu/~mernst/pubs/implicit-control-flow-tr150801.pdf extended version;
    https://types.cs.washington.edu/sparta/ SPARTA toolset;
    https://checkerframework.org/ Checker Framework",
  category = "Static analysis,Mobile applications",
  csetags = "rjust,smillst,plvines,wmdietl,mernst,mernst-Static-analysis,plse",
  summary =
   "Standard program analysis understands control flow through direct procedure
    calls.  This paper provides analyses that resolve uses of Java reflecton and
    the data passed in Android intents.",
  undergradCoauthor = 1,
}


@InProceedings{MusluSBE2015,
  author = 	 "K{\i}van{\c{c}} Mu{\c{s}}lu and Luke Swart and Yuriy Brun and Michael D. Ernst",
  authorASCII =  "Kivanc Muslu and Yuriy Brun and Luke Swart and Michael D. Ernst",
  title = 	 "Development history granularity transformations",
  crossref =     "ASE2015",
  pages = 	 "697-702",
 abstract =
   "Development histories can simplify some software
    engineering tasks, but different tasks require different history
    granularities. For example, a history that includes every edit
    that resulted in compiling code is needed when searching for the
    cause of a regression, whereas a history that contains only changes
    relevant to a feature is needed for understanding the evolution of
    the feature. Unfortunately, today, both manual and automated
    history generation result in a single-granularity history. This
    paper introduces the concept of \emph{multi-grained} development history
    views and the architecture of Codebase Manipulation, a tool
    that automatically records a fine-grained history and manages
    its granularity by applying granularity transformations.",
  basefilename = "history-transformations-ase2015",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/history-transformations-ase2015.pdf PDF;
    https://homes.cs.washington.edu/~mernst/pubs/history-transformations-ase2015-slides.pdf slides (PDF);
    https://homes.cs.washington.edu/~mernst/pubs/history-transformations-ase2015-slides.pptx slides (PowerPoint)",
  OLDdownloads =
   "https://bitbucket.org/kivancmuslu/chronos Bread implementation;
    https://bitbucket.org/LukeSwart/untangler Untangler implementation;
    https://bitbucket.org/kivancmuslu/chronos-test-bisection Bisector implemenation",
  category = "Speculative analysis",
  csetags = "kivanc,mernst,mernst-Speculative-analysis,plse",
  summary =
   "This paper shows how to transform a development history into multiple
   granularities that are appropriate for different software engineering tasks.",
  undergradCoauthor = 1,
}


@Article{MusluBEN2015,
  author = 	 "K{\i}van{\c{c}} Mu{\c{s}}lu and Yuriy Brun and Michael D. Ernst and David Notkin",
  authorASCII =  "Kivanc Muslu and Yuriy Brun and Michael D. Ernst and David Notkin",
  title = 	 "Reducing feedback delay of software development tools via continuous analysis",
  journal = 	 TSE,
  year = 	 2015,
  OPTkey = 	 "",
  volume = 	 "41",
  number = 	 "8",
  pages = 	 "745--763",
  month = 	 aug,
  OPTnote = 	 "",
  OPTannote = 	 "",
  abstract =
   "During software development, the sooner a developer learns how code changes
    affect program analysis results, the more helpful that analysis is.
    Manually invoking an analysis may interrupt the developer's workflow or
    cause a delay before the developer learns the implications of the change. A
    better approach is \emph{continuous analysis} tools that always provide
    up-to-date results. We present Codebase Replication, a technique that eases
    the implementation of continuous analysis tools by converting an existing
    offline analysis into an IDE-integrated, continuous tool with two desirable
    properties: isolation and currency. Codebase Replication creates and keeps
    in sync a copy of the developer's codebase. The analysis runs on the copy
    codebase without disturbing the developer and without being disturbed by
    the developer's changes. We developed Solstice, an open-source,
    publicly-available Eclipse plug-in that implements Codebase Replication.
    Solstice has less than 2.5 milliseconds overhead for most common developer
    actions. We used Solstice to implement four Eclipse-integrated continuous
    analysis tools based on the offline versions of FindBugs, PMD, data race
    detection, and unit testing. Each conversion required on average
    710 LoC and 20 hours of implementation effort.
    Case studies indicate that Solstice-based continuous analysis tools are
    intuitive and easy-to-use.",
  basefilename = "offline-continuous-tse2015",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/offline-continuous-tse2015.pdf PDF",
  downloads =
   "https://homes.cs.washington.edu/~mernst/pubs/offline-continuous-esecfse2013-slides.pdf ESEC/FSE 2013 slides (PDF);
    https://homes.cs.washington.edu/~mernst/pubs/offline-continuous-esecfse2013-slides.pptx ESEC/FSE 2013 slides (PowerPoint)",
  OLDdownloads =
    "https://bitbucket.org/kivancmuslu/solstice/ Solstice implementation",
  category = "Speculative analysis",
  csetags = "kivanc,brun,notkin,mernst,mernst-Software-engineering,plse,plse-speculation",
  summary =
   "An offline program analysis runs when the developer invokes it.  A
    continuous analysis operates automatically on the current codebase and
    asynchronously informs the developer of results.  By using a shadow copy of
    the codebase, an offline analysis can be made continuous.",
}


@InProceedings{ErnstLMSS2015,
  author = 	 "Michael D. Ernst and Alberto Lovato and Damiano Macedonio and Ciprian Spiridon and Fausto Spoto",
  title = 	 "Boolean formulas for the static identification of injection attacks in {Java}",
  crossref =     "LPAR2015",
  pages = 	 "130--145",
  abstract =
   "The most dangerous security-related software errors, according to CWE 2011,
    are those leading to injection attacks --- user-provided data that result
    in undesired database access and updates (\emph{SQL-injec\-tions}), dynamic
    generation of web pages (\emph{cross-site scripting-injections}),
    redirection to user-specified web pages (\emph{redirect-injections}),
    execution of OS commands (\emph{command-injections}), class loading of
    user-specified classes (\emph{reflection-injections}), and many others.
    This paper describes a flow- and context-sensitive static analysis that
    automatically identifies if and where injections of tainted data can occur
    in a program.  The analysis models explicit flows of tainted data.  Its
    notion of taintedness applies also to reference (non-primitive) types
    dynamically allocated in the heap, and is object-sensitive and
    field-sensitive.  The analysis works by translating the program into
    Boolean formulas that model all possible flows.  We implemented it within
    the Julia analyzer for Java and Android. Julia found injection security
    vulnerabilities in the Internet banking service and in the customer
    relationship management of a large Italian bank.",
  basefilename = "detect-injections-lpar2015",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/detect-injections-lpar2015.pdf PDF;
    https://homes.cs.washington.edu/~mernst/pubs/detect-injections-lpar2015-slides.pdf slides (PDF)",
  category = "Security,Static analysis,Mobile applications",
  csetags = "mernst,mernst-Static-analysis,plse",
  summary =
   "This paper describes a flow- and context-sensitive static analysis that
    automatically identifies where injections of tainted data can occur in
    a program.",
}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%% 2016
%%%

@InProceedings{WoosWATEA2016,
  author = 	 "Doug Woos and James R. Wilcox and Steve Anton and Zachary Tatlock and Michael D. Ernst and Thomas Anderson",
  title = 	 "Planning for change in a formal verification of the {Raft} consensus protocol",
  crossref =     "CPP2016",
  pages = 	 "154-165",
  abstract =
   "We present the first formal verification of state machine safety for
    the Raft consensus protocol, a critical component of many distributed
    systems.  We connected our proof to previous work to establish an
    end-to-end guarantee that our implementation provides linearizable
    state machine replication.  This proof required iteratively discovering
    and proving 90 system invariants.  Our verified implementation
    is extracted to OCaml and runs on real networks.
    \par
    The primary challenge we faced during the verification process
    was proof maintenance, since proving one invariant often required
    strengthening and updating other parts of our proof.  To address this
    challenge, we propose a methodology of planning for change during
    verification.  Our methodology adapts classical information hiding
    techniques to the context of proof assistants, factors out common
    invariant-strengthening patterns into custom induction principles,
    proves higher-order lemmas that show any property proved about a
    particular component implies analogous properties about related
    components, and makes proofs robust to change using structural
    tactics.  We also discuss how our methodology may be applied to
    systems verification more broadly.",
  basefilename = "raft-proof-cpp2016",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/raft-proof-cpp2016.pdf PDF;
    https://homes.cs.washington.edu/~mernst/pubs/raft-proof-cpp2016-slides.pdf slides (PDF)",
  downloads =
    "https://verdi.uwplse.org/ Verdi website;
     https://github.com/uwplse/verdi Verdi implementation;
     https://github.com/uwplse/verdi/tree/cpp2015 Raft implementation and proofs",
  category = "Distributed systems,Verification",
  csetags = 	 "jrw12,dwoos,pavpan,ztatlock,xi,mernst,tom,mernst-Verification,plse",
  summary =
   "This paper provides a formal proof of correctness for a runnable
    implementation of the widely-used Raft consensus algorithm. It also discusses
    how to manage the incremental process of constructing such a proof.",
  undergradCoauthor = 1,
}


@TechReport{WeitzWTEKT2016:TR,
  author = 	 "Konstantin Weitz and Doug Woos and Emina Torlak and Michael D. Ernst and Arvind Krishnamurthy and Zachary Tatlock",
  title = 	 "Bagpipe: Verified {BGP} configuration checking",
  institution =  UWCSEDept,
  year = 	 2016,
  number = 	 "UW-CSE-16-01-01",
  address = 	 UWCSEaddr,
  month = 	 jan,
  abstract =
   "To reliably and securely route traffic across the Internet, Internet
    Service Providers (ISPs) must configure their Border Gateway Protocol (BGP)
    routers to implement policies restricting how routing information can be
    exchanged with other ISPs.
    Correctly implementing these policies in low-level router configuration
    languages, with configuration code distributed across all of an ISP's
    routers, has proven challenging in practice, and misconfiguration has led
    to extended worldwide outages and traffic hijacks.
    \par
    We present Bagpipe, a system that enables ISPs to concisely express their
    policies and automatically check that router configurations adhere to these
    policies.
    To check policies efficiently, Bagpipe introduces the initial network
    reduction, exploits modern satisfiability solvers by building on the
    Rosette framework for solver-aided tools, and parallelizes configuration
    checking across many nodes.
    To ensure Bagpipe correctly checks configurations, we verified its
    implementation in Coq, which required developing both a new framework for
    verifying solver-aided tools and also the first formal semantics for BGP
    based on RFC~4271.
    \par
    To validate the effectiveness of our verified checker, we ran it
    on the router configurations of Internet2, a nationwide ISP\@.
    Bagpipe revealed 19 violations of standard BGP router
    policies without issuing any false positives.
    To validate our BGP semantics, we performed random differential testing
    against C-BGP, a popular BGP simulator.
    We found no bugs in our semantics and one bug in C-BGP\@.",
  basefilename = "bgp-configuration-tr160101",
  downloads =
   "https://github.com/uwplse/uwplse-bagpipe Bagpipe implementation",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/bgp-configuration-tr160101.pdf PDF",
  supersededby = "WeitzWTEKT2016",
  category = "Distributed systems,Verification",
  csetags = 	 "weitzkon,dwoos,emina,mernst,arvind,ztatlock,mernst-Verification,plse",
  summary =
   "This paper presents Bagpipe, a verification tool for BGP configurations.
    Bagpipe has been proven correct, which required a mechanised semantics for
    BGP.  Bagpipe found multiple errors in real-world BGP configurations.",
}


@Article{BeschastnikhWBE2016acmqueue,
  author =       "Ivan Beschastnikh and Patty Wang and Yuriy Brun and Michael D. Ernst",
  title =        "Debugging distributed systems: Challenges and options for validation and debugging",
  journal =      acmqueue,
  year =         2016,
  volume =    14,
  number =    2,
  pages =     "91-110",
  month =     mar # "/" # apr,
  abstract =
   "Distributed systems pose unique challenges for software
    developers. Reasoning about concurrent activities of system nodes and even
    understanding the system's communication topology can be difficult. A
    standard approach to gaining insight into system activity is to analyze
    system logs. Unfortunately, this can be a tedious and complex process. This
    article looks at several key features and debugging challenges that
    differentiate distributed systems from other kinds of software. The article
    presents several promising tools and ongoing research to help resolve these
    challenges.",
  basefilename = "debug-distributed-queue2016",
  downloads =
   "https://bestchai.bitbucket.io/shiviz/ online deployment (try it!);
    https://github.com/DistributedClocks/shiviz ShiVector and ShiViz source code;
    https://bestchai.bitbucket.io/shiviz-demo/ video demo (YouTube)",
  supersededby = "BeschastnikhWBE2016",
  category = "Debugging,Distributed systems",
  csetags = "ivanb,brun,mernst,mernst-Distributed-systems,proj-synoptic,plse",
  summary =
   "This paper presents two dools to help developers comprehend distributed
    systems:  ShiVector to add vector timestamps to distributed system logs
    and ShiViz to visualize such logs as space-time diagrams.",
  undergradCoauthor = 1,
}


@InProceedings{ErnstLMST2016,
  author = 	 "Michael D. Ernst and Alberto Lovato and Damiano Macedonio and Fausto Spoto and Javier Thaine",
  title = 	 "Locking discipline inference and checking",
  crossref =     "ICSE2016",
  pages = 	 "1133-1144",
  abstract =
   "Concurrency is a requirement for much modern software, but the
    implementation of multithreaded algorithms comes at the risk of errors
    such as data races.  Programmers can prevent data races by documenting
    and obeying a locking discipline, which indicates which locks must be
    held in order to access which data.
    \par
    This paper introduces a formal semantics for locking specifications that
    gives a guarantee of race freedom.  A notable difference from most other
    semantics is that it is in terms of values (which is what the runtime
    system locks) rather than variables.  The paper also shows how to express
    the formal semantics in two different styles of analysis:  abstract
    interpretation and type theory.  We have implemented both analyses, in
    tools that operate on Java.  To the best of our knowledge, these are the
    first tools that can soundly infer and check a locking discipline for
    Java.  Our experiments compare the implementations with one another and
    with annotations written by programmers, showing that the ambiguities and
    unsoundness of previous formulations are a problem in practice.",
  usesDaikonAsTestSubject = "1",
  basefilename = "locking-inference-checking-icse2016",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/locking-inference-checking-icse2016.pdf PDF",
  downloads =
   "https://checkerframework.org/ checking implementation",
  OLDdownloads =
   "https://portal.juliasoft.com/ inference implementation;
    https://checkerframework.org/ checking implementation",
  category = "Concurrency,Verification",
  csetags = "mernst,jthaine,mernst-Static-analysis,plse",
  summary =
   "This paper describes an abstract inference and a type system and for
    inferring and checking a locking discipline that provides value protection.
    It also compares programmer-written annotations to implementations of each.",
}


@InProceedings{ErnstMMS2016,
  author = 	 "Michael D. Ernst and Damiano Macedonio and Massimo Merro and Fausto Spoto",
  title = 	 "Semantics for locking specifications",
  crossref =     "NFM2016",
  pages =     "355-372",
  abstract =
   "Lock-based synchronization disciplines, like Java's \texttt{@GuardedBy},
    are widely used to prevent concurrency errors.  However, their semantics is
    often expressed informally and is consequently ambiguous.  This article
    highlights such ambiguities and overcomes them by formalizing two possible
    semantics of \texttt{@GuardedBy}, using a reference operational semantics
    for a core calculus of a concurrent Java-like language.  It also identifies
    when such annotations are actual guarantees against data races. Our work
    aids in understanding the annotations and supports the development of sound
    tools that verify or infer them.",
  basefilename = "locking-semantics-nfm2016",
  downloads =
   "https://checkerframework.org/ checking implementation",
  OLDdownloads =
   "https://portal.juliasoft.com/ inference implementation;
    https://checkerframework.org/ checking implementation",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/locking-semantics-nfm2016.pdf PDF",
  category = "Concurrency,Verification",
  csetags = "mernst,mernst-Static-analysis,plse",
  summary =
   "Java's @GuardedBy annotation is intended to prevent race conditions, but
    current tools give it a definition that permits race conditions.  This paper
    formalizes a correct definition that prevents race conditions as intended.",
}


@InProceedings{LoncaricTE2016,
  author = 	 "Calvin Loncaric and Emina Torlak and Michael D. Ernst",
  title = 	 "Fast synthesis of fast collections",
  crossref =     "PLDI2016",
  pages = 	 "355-368",
  abstract =
   "Many applications require specialized data structures not found in the
    standard libraries, but implementing new data structures by hand is tedious
    and error-prone. This paper presents a novel approach for synthesizing
    efficient implementations of complex collection data structures from
    high-level specifications that describe the desired retrieval operations.
    Our approach handles a wider range of data structures than previous work,
    including structures that maintain an order among their elements or have
    complex retrieval methods. We have prototyped our approach in a data
    structure synthesizer called Cozy.  Four large, real-world case
    studies compare structures generated by Cozy against
    handwritten implementations in terms of correctness and performance.
    Structures synthesized by Cozy match the performance of handwritten
    data structures while avoiding human error.",
  basefilename = "collection-synthesis-pldi2016",
  downloads =
   "https://github.com/CozySynthesizer/cozy Cozy implementation",
  category = "Synthesis",
  csetags = 	 "loncaric,emina,mernst,mernst-Synthesis,plse",
  summary =
   "The Cozy tool takes as input a specification for a collection data structure
    and query operations, and produces as output an efficient implementation.
    Cozy decomposes the problem into two parts by first synthesizing an
    ``outline'' in terms of high-level operations.",
}


@InProceedings{GoffiGEP2016,
  author =       "Alberto Goffi and Alessandra Gorla and Michael D. Ernst and Mauro Pezz{\`e}",
  authorASCII1 =       "Alberto Goffi and Alessandra Gorla and Michael D. Ernst and Mauro Pezze",
  authorASCII2 =       "Alberto Goffi and Alessandra Gorla and Michael D. Ernst and Mauro Pezzè",
  title =        "Automatic generation of oracles for exceptional behaviors",
  crossref =     "ISSTA2016",
  pages =     "213--224",
  abstract =
   "Test suites should test exceptional behavior to detect
    faults in error-handling code. However, manually-written test suites
    tend to neglect exceptional behavior. Automatically-generated test
    suites, on the other hand, lack test oracles that verify whether
    runtime exceptions are the expected behavior of the code under test.
    \par
    This paper proposes a technique that automatically creates test oracles for
    exceptional behaviors from Javadoc comments. The technique uses a combination
    of natural language processing and run-time instrumentation.
    Our implementation, Toradocu, can be combined with a test input
    generation tool. Our experimental evaluation shows that Toradocu
    improves the fault-finding effectiveness of
    EvoSuite and Randoop test suites by 8\% and 16\% respectively, and
    reduces EvoSuite's false positives by 33\%.",
  basefilename = "exception-oracles-issta2016",
  downloads = "https://github.com/albertogoffi/toradocu Toradocu implementation",
  category = "Natural language processing,Test generation",
  csetags = "mernst,mernst-Natural-language-processing,plse",
  summary =
   "This paper gives a technique that converts English documentation about
    thrown exceptions (say, expressed in Javadoc) into assertions that determine
    whether a program throws the correct exceptions."
}


@InProceedings{PernsteinerLTTWEJ2016,
  author =       "Stuart Pernsteiner and Calvin Loncaric and Emina Torlak and Zachary Tatlock and Xi Wang and Michael D. Ernst and Jonathan Jacky",
  title =        "Investigating safety of a radiotherapy machine using system models with pluggable checkers",
  crossref =     "CAV2016",
  pages =     "23-41",
  abstract =
    "Formal techniques for guaranteeing software correctness have made
    tremendous progress in recent decades.
    However, applying these techniques to real-world safety-critical
    systems remains challenging in practice.
    Inspired by goals set out in prior work, we report on a large-scale case
    study that applies modern verification techniques to check safety
    properties of a radiotherapy system in current clinical use.
    Because of the diversity and complexity of the system's components (software,
    hardware, and physical), no single tool was suitable for both checking
    critical component properties and ensuring that their composition
    implies critical system properties.
    This paper describes how we used state-of-the-art approaches to develop
    specialized tools for verifying safety properties of individual components,
    as well as an extensible tool for composing those properties to check the
    safety of the system as a whole.
    We describe the key design decisions that diverged from previous approaches
    and that enabled us to practically apply our approach to provide
    machine-checked guarantees.
    Our case study uncovered subtle safety-critical flaws in a pre-release of
    the latest version of the radiotherapy system's control software.",
  basefilename = "neutrons-cav2016",
  category = "Verification",
  csetags =   "spernste,loncaric,emina,ztatlock,xi,mernst,mernst-Verification,plse",
  summary =
   "This paper describes a site of tools that we built to verify properties
    of a clinical radiotherapy system, and a Safety Case Checker (SCC) that
    connects them into a end-to-end safety argument.",
}


@Article{BeschastnikhWBE2016,
  author =       "Ivan Beschastnikh and Patty Wang and Yuriy Brun and Michael D. Ernst",
  title =        "Debugging distributed systems: Challenges and options for validation and debugging",
  journal =      cacm,
  year =         2016,
  volume =    59,
  number =    8,
  pages =     "32--37",
  month =    aug,
  abstract =
   "Distributed systems pose unique challenges for software
    developers. Reasoning about concurrent activities of system nodes and even
    understanding the system's communication topology can be difficult. A
    standard approach to gaining insight into system activity is to analyze
    system logs. Unfortunately, this can be a tedious and complex process. This
    article looks at several key features and debugging challenges that
    differentiate distributed systems from other kinds of software. The article
    presents several promising tools and ongoing research to help resolve these
    challenges.",
  basefilename = "debug-distributed-cacm2016",
  downloads =
   "https://bestchai.bitbucket.io/shiviz/ online deployment (try it!);
    https://github.com/DistributedClocks/shiviz ShiVector and ShiViz source code;
    https://bestchai.bitbucket.io/shiviz-demo/ video demo (YouTube)",
  supersededby = "BeschastnikhLXWBE2020",
  category = "Debugging,Distributed systems",
  csetags = "ivanb,brun,mernst,mernst-Distributed-systems,proj-synoptic,plse",
  summary =
   "This paper presents two dools to help developers comprehend distributed
    systems:  ShiVector to add vector timestamps to distributed system logs
    and ShiViz to visualize such logs as space-time diagrams.",
  undergradCoauthor = 1,
}


@InProceedings{WeitzWTEKT2016:NetPL,
  author = 	 "Konstantin Weitz and Doug Woos and Emina Torlak and Michael D. Ernst and Arvind Krishnamurthy and Zachary Tatlock",
  title =        "Formal Semantics and Automated Verification for the {Border} {Gateway} {Protocol}",
  crossref =     "NetPL2016",
  numpages =    2,
  NOpages =     "Maybe no proceedings; not in ACM Digital Library as of 4/26/2017",
  basefilename = "bagpipe-overview-netpl2016",
  downloads =
   "https://github.com/uwplse/uwplse-bagpipe Bagpipe implementation",
  supersededby = "WeitzWTEKT2016 An overview",
  category = "Distributed systems,Verification",
  csetags = 	 "weitzkon,dwoos,emina,mernst,arvind,ztatlock,mernst-Verification,plse",
  summary =
   "This brief paper overviews the Bagpipe project, which does
    formal verification of control-plane policies for BGP configurations.",
}


@TechReport{PearsonCJFAEPK2016,
  author =       "Spencer Pearson and Jos\'e Campos and Ren\'e Just and Gordon Fraser and Rui Abreu and Michael D. Ernst and Deric Pang and Benjamin Keller",
  authorASCII =       "Spencer Pearson and Jose Campos and Rene Just and Gordon Fraser and Rui Abreu and Michael D. Ernst and Deric Pang and Benjamin Keller",
  title =        "Evaluating \& improving fault localization techniques",
  institution =  UWCSEDept,
  year =         2016,
  number = 	 "UW-CSE-16-08-03",
  address =   UWCSEaddr,
  month =     sep,
  note = 	 "Revised " # feb # " 2017",
  abstract =
   "A fault localization technique takes as input a faulty program, and it
    produces as output a ranked list of suspicious code locations at which the
    program may be defective.  When researchers propose a new fault
    localization technique, they evaluate it on programs with known faults;
    they score the technique based on where in its output list the defective
    code appears.  This enables comparison of multiple fault localization
    techniques to determine which one is better.
    \par
    Previous research has evaluated fault localization techniques using
    artificial faults, generated either by mutation tools or
    manually.  In other words, previous research has determined which fault
    localization techniques are best at finding artificial faults.  However, it
    is not known which fault localization techniques are best at finding real
    faults.  It is not obvious that the answer is the same, given previous work
    showing that artificial faults have both similarities to and differences
    from real faults.
    \par
    We performed a replication study to evaluate 10 claims in the literature
    that compared fault localization techniques.  We used
    2273 artificial
    faults in 5 real-world programs.  Our results refute 3 of
    the previous claims.  Then, we evaluated the same 10 claims, using
    297 \emph{real} faults from the
    5 programs.  Every previous result was refuted or was
    statistically insignificant.  In other words, our experiments show that
    artificial faults are not useful for predicting which fault localization
    techniques perform best on real faults.
    \par
    In light of these results, we identified a design space that includes many
    previously-studied fault localization techniques as well as hundreds of new
    techniques.  We experimentally determined which factors in the design space
    are most important.  Then, we extended it with new techniques.  Several of
    our novel techniques outperform all existing techniques, notably in terms
    of ranking defective code in the top-5 or top-10 reports.",
  basefilename = "fault-localization-tr160803",
  downloads = "https://bitbucket.org/rjust/fault-localization-data data and scripts",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/fault-localization-tr160803.pdf PDF",
  supersededby = "PearsonCJFAEPK2017 An extended version",
  category = "Debugging",
  csetags = 	 "suspense,mernst,dericp,bjkeller,mernst-Testing,plse",
  summary =
   "Previously, fault localization techniques were evaluated on artificial
    faults, such as mutants.  None of the previously-reported results holds for
    real faults, indicating that artificial faults should not be used to
    evaluate fault localization techniques.",
  undergradCoauthor = 1,
}


@InProceedings{NandiE2016,
  author = 	 "Chandrakana Nandi and Michael D. Ernst",
  title = 	 "Automatic trigger generation for rule-based smart homes",
  crossref =     "PLAS2016",
  pages = 	 "97-102",
  abstract =
   "To customize the behavior of a smart home, an end user writes rules.
    When an external event satisfies the rule's trigger, the rule's action
    executes; for example, when the temperature is above a certain
    threshold, then window awnings might be extended.  End users often write
    incorrect rules.  This paper presents a technique that prevents
    \textit{errors due to too few triggers} in the rules.  The technique
    statically analyzes a rule's actions to determine what triggers are
    necessary.
    \par
    We implemented the technique in a tool called TrigGen and tested it on
    96 end user written rules for openHAB, an open-source home automation
    platform.  It identified that 80\% of the rules had fewer triggers than
    required for correct behavior.  The missing triggers could lead to
    unexpected behavior and security vulnerabilities in a smart home.",
  basefilename = "trigger-generation-plas2016",
  downloads =
   "https://docs.google.com/a/cs.washington.edu/presentation/d/1lW9zagndSkCdqtYgLK9WXwjUnhsFkG30xF7Ggoam3N4/edit slides (Google Slides)",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/pubs/trigger-generation-plas2016.pdf PDF;
    https://homes.cs.washington.edu/~mernst/pubs/trigger-generation-plas2016-slides.pdf slides (PDF)",
  category = "Security",
  csetags = "mernst,cnandi,mernst-Security,plse",
  summary =
   "User-written rules consist of triggers and actions.  If the user forgets to
    write some triggers, then the rules may not fire as often as desired by the
    user, leading to undesired behavior or security errors.  This paper describes
    an analysis to find omitted trigger conditions.",
}


@InProceedings{WeitzWTEKT2016,
  author = 	 "Konstantin Weitz and Doug Woos and Emina Torlak and Michael D. Ernst and Arvind Krishnamurthy and Zachary Tatlock",
  title =        "Scalable verification of {Border} {Gateway} {Protocol} configurations
with an {SMT} solver",
  crossref =     "OOPSLA2016",
  pages =     "765-780",
  abstract =
   "Internet Service Providers (ISPs) use the Border Gateway Protocol (BGP) to
    announce and exchange routes for delivering packets through the internet.
    ISPs must carefully configure their BGP routers to ensure traffic is routed
    reliably and securely.  Correctly configuring BGP routers has proven
    challenging in practice, and misconfiguration has led to worldwide outages
    and traffic hijacks.
    \par
    This paper presents Bagpipe, a system that enables ISPs to declaratively
    express BGP policies and that automatically verifies that router
    configurations implement such policies.  The novel \emph{initial network
    reduction} soundly reduces policy verification to a search for
    counterexamples in a finite space.  An SMT-based symbolic execution engine
    performs this search efficiently.  Bagpipe reduces the size of its search
    space using predicate abstraction and parallelizes its search using
    symbolic variable hoisting.
    \par
    Bagpipe's policy specification language is expressive:  we expressed
    policies inferred from real AS configurations, policies from the
    literature, and policies for 10 Juniper TechLibrary configuration
    scenarios.  Bagpipe is efficient:  we ran it on three ASes with a total of
    over 240,000 lines of Cisco and Juniper BGP configuration.  Bagpipe is
    effective:  it revealed 19 policy violations without issuing any false
    positives.",
  basefilename = "bgp-configuration-oopsla2016",
  downloads =
   "https://www.youtube.com/watch?v=eKB5Vj0PsIk talk video;
    https://bagpipe.uwplse.org Bagpipe homepage",
  downloadsnonlocalTODO = "*",
  category = "Distributed systems",
  csetags = 	 "weitzkon,dwoos,emina,mernst,arvind,ztatlock,mernst-Verification,plse",
  summary =
   "This paper presents Bagpipe, a verification tool for BGP configurations.
    Bagpipe has been proven correct, which required a mechanised semantics for
    BGP.  Bagpipe found multiple errors in real-world BGP configurations.",
}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%% 2017
%%%


@TechReport{LinWPVZE2017:TR,
  author =       "Xi Victoria Lin and Chenglong Wang and Deric Pang and Kevin Vu and Luke Zettlemoyer and Michael D. Ernst",
  title =        "Program synthesis from natural language using recurrent neural networks",
  institution =  UWCSEdept,
  year =         2017,
  number =    "UW-CSE-17-03-01",
  address =   UWCSEaddr,
  month =     mar,
  abstract =
   "Oftentimes, a programmer may have difficulty implementing a
    desired operation. Even when the programmer can describe her
    goal in English, it can be difficult to translate into code. Existing
    resources, such as question-and-answer websites, tabulate specific
    operations that someone has wanted to perform in the past, but
    they are not effective in generalizing to new tasks, to compound
    tasks that require combining previous questions, or sometimes even
    to variations of listed tasks.
    \par
    Our goal is to make programming easier and more productive by
    letting programmers use their own words and concepts to express
    the intended operation, rather than forcing them to accommodate
    the machine by memorizing its grammar. We have built a system
    that lets a programmer describe a desired operation in natural
    language, then automatically translates it to a programming language
    for review and approval by the programmer. Our system, Tellina,
    does the translation using recurrent neural networks (RNNs), a
    state-of-the-art natural language processing technique that we
    augmented with slot (argument) filling and other enhancements.
    \par
    We evaluated Tellina in the context of shell scripting. We trained
    Tellina's RNNs on textual descriptions of file system operations
    and bash one-liners, scraped from the web. Although recovering
    completely correct commands is challenging, Tellina achieves top-3
    accuracy of 80\% for producing the correct command structure. In a
    controlled study, programmers who had access to Tellina
    outperformed those who did not, even when Tellina's predictions were
    not completely correct, to a statistically significant degree.",
  basefilename = "nl-command-tr170301",
  downloads =
   "https://kirin.cs.washington.edu:8000/ Tellina website;
    https://github.com/TellinaTool/tellina Tellina implementation",
  TOBEsupersededby = "*",
  category = "Natural language processing,Synthesis",
  csetags = "xilin,clwang,dericp,lsz,mernst,mernst-Natural-language-processing,plse",
  summary =
   "Tellina is a system that translates an English description of a file
   system operation into a bash command.  A controlled user experiment
   shows that it helps programmers perform file system tasks more quickly.",
}


@InProceedings{Ernst2017,
  author =       "Michael D. Ernst",
  title =        "Natural language is a programming language: Applying natural language processing to software development",
  crossref =     "SNAPL2017",
  pages =     "4:1--4:14",
  abstract =
   "A powerful, but limited, way to view software is as source code alone.
    Treating a program as a sequence of instructions enables it to be
    formalized and makes it amenable to mathematical techniques
    such as abstract interpretation and model checking.
    \par
    A program consists of much more than a sequence of instructions.
    Developers make use of test cases, documentation, variable names, program
    structure, the version control repository, and more.  I argue that it is
    time to take the blinders off of software analysis tools:  tools should use
    all these artifacts to deduce more powerful and useful information about
    the program.
    \par
    Researchers are beginning to make progress towards this vision.  This paper
    gives, as examples,
    four results that find bugs and generate code by applying
    \emph{natural language processing} techniques to software artifacts.  The
    four techniques use as input error messages, variable names, procedure
    documentation, and user questions.  They use four different NLP techniques:
    document similarity, word semantics, parse trees, and neural networks.
    \par
    The initial results suggest that this is a promising avenue for
    future work.",
  basefilename = "natural-language-snapl2017",
  category = "Natural language processing",
  csetags =   "mernst,mernst-Software-engineering,plse",
  summary =
   "Software developers embed much natural language (e.g., English) in their
    code, including in error messages, variable names, and comments.  This paper
    advocates analyzing the natural language as well as the source code.",
}


@InProceedings{PearsonCJFAEPK2017,
  author =       "Spencer Pearson and Jos\'e Campos and Ren\'e Just and Gordon Fraser and Rui Abreu and Michael D. Ernst and Deric Pang and Benjamin Keller",
  authorASCII =       "Spencer Pearson and Jose Campos and Rene Just and Gordon Fraser and Rui Abreu and Michael D. Ernst and Deric Pang and Benjamin Keller",
  title =        "Evaluating and improving fault localization",
  crossref =     "ICSE2017",
  pages =        "609-620",
  abstract =
   "Most fault localization techniques take as input a faulty program, and
    produce as output a ranked list of suspicious code locations at which the
    program may be defective.  When researchers propose a new fault
    localization technique, they typically evaluate it on programs with known
    faults. The technique is scored based on where in its output list the
    defective code appears. This enables the comparison of multiple fault
    localization techniques to determine which one is better.
    \par
    Previous research has evaluated fault localization techniques using
    artificial faults, generated either by mutation tools or manually. In other
    words, previous research has determined which fault localization techniques
    are best at finding artificial faults.  However, it is not known which
    fault localization techniques are best at finding real faults. It is not
    obvious that the answer is the same, given previous work showing that
    artificial faults have both similarities to and differences from real
    faults.
    \par
    We performed a replication study to evaluate 10 claims in the literature
    that compared fault localization techniques (from the spectrum-based and
    mutation-based families). We used 3242 artificial faults in 6 real-world
    programs. Our results support 7 of the previous claims as statistically
    significant, but only 3 as having non-negligible effect sizes. Then, we
    evaluated the same 10 claims, using 323 \emph{real} faults from the 6
    programs. Every previous result was refuted or was statistically and
    practically insignificant. Our experiments show that artificial faults are
    not useful for predicting which fault localization techniques perform best
    on real faults.
    \par
    In light of these results, we identified a design space that includes many
    previously-studied fault localization techniques as well as hundreds of new
    techniques. We experimentally determined which factors in the design space
    are most important, using an overall set of 395 real faults. Then, we
    extended this design space with new techniques. Several of our novel
    techniques outperform all existing techniques, notably in terms of ranking
    defective code in the top-5 or top-10 reports.",
  basefilename = "fault-localization-icse2017",
  downloads =
   "https://homes.cs.washington.edu/~mernst/pubs/fault-localization-icse2017-slides-long.pptx longer slide deck (PowerPoint);
    https://homes.cs.washington.edu/~mernst/pubs/fault-localization-icse2017-slides-long.pdf longer slide deck (PDF);
    https://homes.cs.washington.edu/~mernst/pubs/fault-localization-tr160803.pdf technical report UW-CSE-16-08-03;
    https://bitbucket.org/rjust/fault-localization-data data and scripts",
  TODOdownloadsnonlocal = "",
  TOBEsupersededby = "PearsonCJFAEPK2018",
  category = "Debugging",
  csetags = 	 "suspense,mernst,dericp,bjkeller,mernst-Testing,plse",
  summary =
   "Previously, fault localization techniques were evaluated on artificial
    faults, such as mutants.  None of the previously-reported results holds for
    real faults, indicating that artificial faults should not be used to
    evaluate fault localization techniques.",
  undergradCoauthor = 1,
}


@Article{GordonEGP2017,
  author =       "Colin S. Gordon and Michael D. Ernst and Dan Grossman and Matthew Parkinson",
  title =        "Verifying Invariants of Lock-free Data Structures with Rely-Guarantee and Refinement Types",
  journal =      TOPLAS,
  year =         2017,
  volume =    "39",
  number =    "3",
  pages =     "11:1--11:54",
  month =     may,
  abstract =
   "Verifying invariants of fine-grained concurrent data structures is
    challenging because interference from other threads may occur at any
    time. We propose a new way of proving invariants of fine-grained concurrent
    data structures: applying rely-guarantee reasoning to references in the
    concurrent setting. Rely-guarantee applied to references can verify bounds
    on thread interference, without requiring a whole program to be verified.
    \par
    This paper provides three new results. First, it provides a new approach to
    preserving invariants and restricting usage of concurrent data
    structures. Our approach targets a space between simple type systems and
    modern concurrent program logics, offering an intermediate point between
    unverified code and full verification. Furthermore, it avoids sealing
    concurrent data structure implementations, and can interact safely with
    unverified imperative code. Second, we demonstrate the approach's broad
    applicability through a series of case studies, using two implementations:
    an axiomatic C OQ DSL and a library for Liquid Haskell. Third, these two
    implementations allow us to compare and contrast verifications by
    interactive proof (C OQ ) and a weaker form that can be expressed using
    SMT-discharged dependent refinement types (Liquid Haskell).",
  basefilename = "lockfree-toplas2017",
  category = "Concurrency",
  csetags = "csgordon,mernst,djg,mernst-Verification,plse",
  summary =
   "This paper presents a new approach to verifying lock-free concurrent data
    structures that handles more complex code:  view references as
    capabilities and verify them using rely-guarantee reasoning.",
}


@InProceedings{WeitzLHTET2017,
  author =       "Konstantin Weitz and Steven Lyubomirsky and Stefan Heule and Emina Torlak and Michael D. Ernst and Zachary Tatlock",
  title =        "{SpaceSearch}: A library for building and verifying solver-aided tools",
  crossref =  "ICFP2017",
  pages =     "25:1--25:28",
  abstract =
   "Many verification tools build on automated solvers. These tools reduce
    problems in a specific application domain (e.g., compiler optimization
    validation) to queries that can be discharged with a highly optimized
    solver. But the correctness of the reductions themselves is rarely verified
    in practice, limiting the confidence that the solver's output establishes
    the desired domain-level property.
    \par
    This paper presents SpaceSearch, a new library for developing solver-aided
    tools within a proof assistant.  A user builds their solver-aided tool in
    Coq against the SpaceSearch interface, and the user then verifies that the
    results provided by the interface are sufficient to establish the tool's
    desired high-level properties.  Once verified, the tool can be extracted to
    an implementation in a solver-aided language (e.g., Rosette), where
    SpaceSearch provides an efficient instantiation of the SpaceSearch
    interface with calls to an underlying SMT solver. This combines the strong
    correctness guarantees of developing a tool in a proof assistant with the
    high performance of modern SMT solvers. This paper also introduces new
    optimizations for such verified solver-aided tools, including
    parallelization and incrementalization.
    \par
    We evaluate SpaceSearch by building and verifying two solver-aided
    tools. The first, SaltShaker, checks that RockSalt's x86 semantics agrees
    with STOKE's x86 semantics for a given instruction instantiation. When run
    on 15,255 instruction instantiations, SaltShaker identified 7 bugs in
    RockSalt and 1 bug in STOKE. After these systems were patched by their
    developers, SaltShaker verified the semantics' agreement on these
    instruction instantiations in under 2h. The second tool is a verified
    version of Bagpipe, a Border Gateway Protocol (BGP) router configuration
    checker. Like the previous, unverified, version, our new Bagpipe
    implementation scales to checking industrial configurations spanning over
    240 KLOC, identifying 19 configuration inconsistencies with no false
    positives. Furthermore, in the process of verifying Bagpipe, we identified
    and fixed 2 bugs from the unverified implementation. These results
    demonstrate that SpaceSearch is a practical approach to developing
    efficient, verified solver-aided tools.",
  basefilename = "spacesearch-icfp2017",
  category =  "Verification",
  csetags = 	 "weitzkon,sslyu,emina,mernst,ztatlock,mernst-Verification,plse",
  summary =
   "SpaceSearch is a library for developing solver-aided tools within a proof
    assistant.  It enables the creation of provably correct tools that transform
    some problem from its original doman to that of a highly optimized solver.",
}


@InProceedings{JackyBELPTT2017,
  author =       "Jonathan Jacky and Stefani Banerian and Michael D. Ernst and Calvin Loncaric and Stuart Pernsteiner and Zachary Tatlock and Emina Torlak",
  title =        "Automatic formal verification for {EPICS}",
  crossref =  "ICALEPCS2017",
  NEEDpages =     "*",
  abstract =
   "We built an EPICS-based radiation therapy machine control program and
    are using it to treat patients at our hospital.  To help ensure safety,
    the control program uses a restricted subset of EPICS constructs and programming
    techniques, and we developed several new automated formal verification
    tools for this subset.
    \par
    To check our control program, we built a \emph{Symbolic Interpeter}
    that finds errors in EPICS database programs,
    using symbolic execution and satisfiability
    checking.  It found serious errors in our control program that were
    missed by reviews and testing.
    \par
    To check the EPICS runtime (EPICS Core) itself, we
    first developed a \emph{Formal Semantics} for EPICS database programs,
    based on the EPICS Record Reference Manual (RRM) and expressed in
    the specification language of an automated theorem prover.
    We built a formally-verified \emph{Trace Validator} and
    used it to check the EPICS runtime against our semantics by
    differential testing with millions of randomly generated programs.
    The testing process generally corroborated that the EPICS runtime
    conforms to its specification in the RRM, but it did find several omissions
    and ambiguities in the RRM that might mislead users.
    Our formal semantics for EPICS
    enables valuable future developments: a full proof of correctness
    for our EPICS program, verified analyses for arbitrary EPICS
    programs, and a \emph{Verified Compiler} that could
    compile an EPICS database to a verified standalone program, while
    dispensing with much of the unverified EPICS toolchain and runtime.",
  basefilename = "epics-verification-icalepcs2017",
  downloads = "https://www.youtube.com/watch?v=CFSnkB5z0GA talk video (YouTube)",
  category = "Verification",
  csetags =   "mernst,loncaric,spernste,ztatlock,emina,mernst-Verification,plse",
  summary =
   "This paper presents a symbolic interpreter that detects errors in EPICS
    programs.  It also presents a formal semantics for the EPICS language, which
    revealed omissions and ambiguities in the EPICS specification.",
}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%% 2018
%%%


@InProceedings{LinWZE2018,
  author =       "Xi Victoria Lin and Chenglong Wang and Luke Zettlemoyer and Michael D. Ernst",
  title =        "{NL2Bash}: A corpus and semantic parser for natural language interface to the {Linux} operating system",
  crossref =  "LREC2018",
  NEEDpages =     "*",
  abstract =
   "We present new data and semantic parsing methods for the problem of mapping
    English sentences to Bash commands (NL2Bash). Our long-term goal is to
    enable any user to perform operations such as file manipulation, search,
    and application-specific scripting by simply stating their goals in
    English. We take a first step in this domain, by providing a new dataset of
    challenging but commonly used Bash commands and expert-written English
    descriptions, along with baseline methods to establish performance levels
    on this task.",
  basefilename = "nl2bash-corpus-lrec2018",
  downloads = "https://github.com/TellinaTool/nl2bash dataset",
  category = "Natural language processing,Synthesis",
  csetags = "xilin,clwang,lsz,mernst,mernst-Natural-language-processing,plse",
  summary =
   "NL2Bash is a dataset containing pairs of (English text, Bash commands).
    This dataset can be used in training and evaluating tools that translate
    from English to bash."
}


@InProceedings{LoncaricET2018,
  author =       "Calvin Loncaric and Michael D. Ernst and Emina Torlak",
  title =        "Generalized data structure synthesis",
  crossref =  "ICSE2018",
  pages =     "958-968",
  abstract =
   "Data structure synthesis is the task of generating data structure
    implementations from high-level specifications.  Recent work in this area
    has shown potential to save programmer time and reduce the risk of defects.
    Existing techniques focus on data structures
    for manipulating subsets of a single collection, but real-world
    programs often track multiple related collections and
    aggregate properties such as sums, counts, minimums, and maximums.
    \par
    This paper shows how to synthesize data structures that track subsets and
    aggregations of multiple related collections.
    Our technique decomposes the synthesis task into alternating steps of
    \emph{query synthesis} and \emph{incrementalization}.  The query synthesis step
    implements pure operations over the data structure state by leveraging existing
    enumerative synthesis techniques, specialized to the data
    structures domain.  The incrementalization step implements imperative state
    modifications by re-framing them as fresh queries that determine what to
    change, coupled with a small amount of code to apply the change.  As an added
    benefit of this approach over previous work, the synthesized data structure
    is optimized for not only the queries in the specification but also the required
    update operations.
    We have evaluated our approach in four large case studies,
    demonstrating that these extensions are broadly applicable.",
  basefilename = "generalized-synthesis-icse2018",
  downloads =
   "https://github.com/CozySynthesizer/cozy Cozy implementation",
  TODOdownloadsnonlocal = "*",
  category = "Synthesis",
  csetags = 	 "loncaric,emina,mernst,mernst-Synthesis,plse",
  summary =
   "This paper shows how to synthesize a data structure that tracks subsets and
   aggregations of multiple related collections.  The input is a trivial
   implementation of the desired API operations, and the output is an efficient
   implementation.",
}


@InProceedings{PanchekhaGETK2018,
  author =       "Pavel Panchekha and Adam Geller and Michael D. Ernst and Zachary Tatlock and Shoaib Kamil",
  title =        "Verifying that web pages have accessible layout",
  crossref =  "PLDI2018",
  pages =     "1-14",
  abstract =
   "Usability and accessibility guidelines aim
      to make graphical user interfaces accessible to all users,
      by, say, requiring that
      text is sufficiently large,
      interactive controls are visible,
      and heading size corresponds to importance.
    These guidelines must hold on the infinitely many possible renderings
      of a web page generated by differing screen sizes, fonts, and other user
      preferences.
    Today, these guidelines are tested by manual inspection
      of a few renderings,
      because 1) the guidelines are not expressed in a formal language,
      2) the semantics of browser rendering are not well understood,
      and 3) no tools exist to check all possible renderings of a web page.
    VizAssert solves these problems.
    First, it introduces \emph{visual logic} to precisely specify accessibility properties.
    Second, it formalizes a large fragment
      of the \emph{browser rendering algorithm}
      using novel \emph{finitization reductions}.
    Third, it provides a \emph{sound, automated tool} for verifying assertions in visual logic.
    \par
    We encoded 14 assertions drawn from best-practice
      accessibility and mobile-usability guidelines in visual logic.
    VizAssert checked them on 62 professionally designed web pages.
    It found 64 distinct errors in the web pages, while
      reporting only 13 false positive warnings.",
  basefilename = "verify-layout-pldi2018",
  downloads = "https://cassius.uwplse.org/ VizAssert and Cassius tools",
  category =  "User interfaces,Mobile applications",
  csetags =   "pavpan,atgeller,mernst,ztatlock,mernst-Verification,plse",
  summary =
   "The VizAssert tool proves that a web page's layout satisfies a usability
    or accessibility property, such as that text never overlaps or buttons
    are onscreen, regardless of screen size, font preferences, browser, etc.",
}



@InProceedings{JustPDE2018,
  author =       "Ren\'e Just and Chris Parnin and Ian Drosos and Michael D. Ernst",
  authorASCII = "Rene Just and Chris Parnin and Ian Drosos and Michael D. Ernst",
  title =        "Comparing developer-provided to user-provided tests for fault localization and automated program repair",
  crossref =  "ISSTA2018",
  pages =     "287-297",
  abstract =
   "To realistically evaluate a software testing or debugging technique, it
    must be run on defects and tests that are characteristic of
    those a developer would encounter in practice.
    For example, to determine the utility of a fault localization or automated
    program repair technique, it
    could be run on real defects from a bug tracking system, using real
    tests that are committed to the version control repository along with the
    fixes.  Although such a methodology uses real tests, it may not use tests
    that are characteristic of the information a developer or
    tool would have in practice.  The tests that a developer commits \emph{after}
    fixing a defect may encode more information than was available
    to the developer when initially diagnosing the defect.
    \par
    This paper compares, both quantitatively and qualitatively, the
    developer-provided tests
    committed along with fixes (as found in the version control repository)
    versus the user-provided tests extracted from bug reports (as found in the
    issue tracker).
    It provides evidence that developer-provided tests are more targeted
    toward the defect and encode more information than user-provided tests.
    For fault localization, developer-provided tests overestimate a
    technique's ability to rank a defective statement in the list of the
    top-n most suspicious statements.
    For automated program repair, developer-provided tests overestimate a
    technique's ability to (efficiently) generate correct patches---user-provided
    tests lead to fewer correct patches and increased repair time.
    This paper also provides suggestions for improving the design and evaluation
    of fault localization and automated program repair techniques.",
  basefilename = "test-provenance-issta2018",
  downloads =
   "https://docs.google.com/presentation/d/1vdkSkkue-jsk5VdUtcXwYIZ0_2bJlfBvqxH5xUuaMgk/edit?usp=sharing slides (Google Slides);
    https://github.com/rjust/defects4j data",
  category =  "Testing",
  csetags =   "rjust,mernst,mernst-Testing,plse",
  summary =
   "Fault localization experiments are usually performed using tests commited
    to found in version control systems.  These may have been committed after
    the developer had investigated a fix.  Using test cases from issue trackers,
    as would be the case in realistic practice, leads to worse fault
    localization results.",
}


@InProceedings{BlasiGKGEPC2018,
  author =    "Arianna Blasi and Alberto Goffi and Konstantin Kuznetsov and Alessandra Gorla and Michael D. Ernst and Mauro Pezz\`e and Sergio Delgado Castellanos",
  authorASCII =    "Arianna Blasi and Alberto Goffi and Konstantin Kuznetsov and Alessandra Gorla and Michael D. Ernst and Mauro Pezze and Sergio Delgado Castellanos",
  authorASCII2 =    "Arianna Blasi and Alberto Goffi and Konstantin Kuznetsov and Alessandra Gorla and Michael D. Ernst and Mauro Pezzè and Sergio Delgado Castellanos",
  title =     "Translating code comments to procedure specifications",
  crossref =  "ISSTA2018",
  pages =     "242-253",
  abstract =
   "Procedure specifications are useful in many software development
    tasks.
    As one example, in automatic test case generation
    they can guide testing, act as test
    oracles able to reveal bugs, and identify illegal inputs.
    Whereas formal specifications are
    seldom available in practice, it is standard practice for developers
    to document their code with semi-structured comments.
    These comments express the
    procedure specification with a mix of predefined tags and natural
    language.
    This paper presents Jdoctor, an approach that combines
    pattern, lexical, and semantic matching to
    translate Javadoc comments into executable procedure specifications
    written as Java expressions.
    In an empirical evaluation, Jdoctor achieved precision of
    92\% and recall of 83\% in
    translating Javadoc into procedure specifications.
    We also supplied the Jdoctor-derived specifications to an
    automated test case generation tool, Randoop.
    The specifications enabled Randoop to generate test cases that
    produce fewer false alarms and reveal more defects.",
  basefilename = "comments-specs-issta2018",
  downloads = "https://github.com/albertogoffi/toradocu Jdoctor implementation",
  category = "Test generation,Natural language processing",
  csetags = "mernst,mernst-Natural-language-processing,plse",
  summary =
   "This paper gives an improved technique that converts English Javadoc
    procedure documentation (preconditions, postconditions, exceptions)
    into executable expresssions that can be used as assertions."
}


@InProceedings{KelloggDME2018,
  author =       "Martin Kellogg and Vlastimil Dort and Suzanne Millstein and Michael D. Ernst",
  title =        "Lightweight verification of array indexing",
  crossref =  "ISSTA2018",
  pages =     "3-14",
  abstract =
   "In languages like C, out-of-bounds array accesses lead to security
    vulnerabilities and crashes. Even in managed languages like Java, which
    check array bounds at run time, out-of-bounds accesses cause exceptions
    that terminate the program.
    \par
    We present a lightweight type system that certifies, at compile time,
    that array accesses in the program are in-bounds. The type system
    consists of several cooperating hierarchies of dependent types,
    specialized to the domain of array bounds-checking. Programmers write
    type annotations at procedure boundaries, allowing modular verification
    at a cost that scales linearly with program size.
    \par
    We implemented our type system for Java in a tool called the Index
    Checker. We evaluated the Index Checker on over 100,000 lines of
    open-source code and discovered array access errors even in
    well-tested, industrial projects such as Google Guava.",
  basefilename = "array-indexing-issta2018",
  downloads = "https://checkerframework.org/ implementation",
  OPTdownloadsnonlocal = "",
  category = "Verification",
  csetags =   "kelloggm,smillst,mernst,mernst-Verification,plse",
  summary =
   "This paper presents a fast, precise, scalable, easy-to-use, static
    verification technique for proving that all array accesses are within
    their bounds, based on multiple simple cooperating type systems.",
}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%% 2019
%%%

@InProceedings{MichaelWAET2019,
  author = 	 "Ellis Michael and Doug Woos and Thomas Anderson and Michael D. Ernst and Zachary Tatlock",
  title = 	 "Teaching rigorous distributed systems with efficient model checking",
  crossref =  "EuroSys2019",
  pages = 	 "1-15",
  basefilename = "dslabs-eurosys2019",
  abstract =
   "Writing correct distributed systems code is difficult, especially for
    novice programmers. The inherent asynchrony and need for fault-tolerance
    make errors almost inevitable.  Industrial-strength testing and model
    checking have been shown to be effective at uncovering bugs, but they come
    at a cost --- in both time and effort --- that is far beyond what students
    can afford. To address this, we have developed an efficient model checking
    framework and visual debugger for distributed systems, with the goal of
    helping students find and fix bugs in near real-time.  We identify two
    novel techniques for reducing the search state space to more efficiently
    find bugs in student implementations. We report our experiences using these
    tools to help over two hundred students build a correct, linearizable,
    fault-tolerant, dynamically-sharded key--value store.",
  category =  "Distributed systems,Education",
  csetags = 	 "emichael,dwoos,tom,mernst,ztatlock,mernst-Distributed-systems,plse",
  summary =
   "This paper introduces shows an effective way to teach distributed systems,
    with a set of labs, and a model checker and visual debugger used by
    students to verify and debug their solutions."
}


@Article{ZouLXEZ2019,
  author = 	 "Daming Zou and Jingjing Liang and Yingfei Xiong and Michael D. Ernst and Lu Zhang",
  title = 	 "An empirical study of fault localization families and their combinations",
  journal = 	 TSE,
  year = 	 2019,
  volume = 	 "47",
  NEEDnumber = 	 "*",
  pages = 	 "332-347",
  month = 	 feb,
  basefilename = "fl-families-tse2019",
  abstract =
   "The performance of fault localization techniques is critical to their
    adoption in practice. This paper reports on an empirical study of a wide
    range of fault localization techniques on real-world faults. Different
    from previous studies, this paper (1) considers a wide range of
    techniques from different families, (2) combines different techniques,
    and (3) considers the execution time of different techniques. Our results
    reveal that a combined technique significantly outperforms any individual
    technique (200\% increase in faults localized in Top 1), suggesting that
    combination may be a desirable way to apply fault localization techniques
    and that future techniques should also be evaluated in the combined
    setting. Our implementation is publicly available for evaluating and
    combining fault localization techniques.",
  downloads = "https://combinefl.github.io CombineFL tool",
  category = "Debugging",
  csetags = 	 "mernst,mernst-Testing,plse",
  summary =
   "This paper evaluates multiple fault localization techniques on
    real-world faults, and indicates how to combine them to improve
    them further.",
}


@Article{PanchekhaDTK2019,
  author = 	 "Pavel Panchekha and Michael D. Ernst and Zachary Tatlock and Shoaib Kamil",
  title = 	 "Modular verification of web page layout",
  journal = 	 PACMPL,
  year = 	 2019,
  volume = 	 3,
  number = 	 151,
  pages = 	 26,
  note = 	 "OOPSLA",
  abstract =
   "Automated verification can ensure that a web page satisfies accessibility,
    usability, and design properties regardless of the end user's device,
    preferences, and assistive technologies. However, state-of-the-art
    verification tools for layout properties do not scale to large pages
    because they rely on whole-page analyses and must reason about the entire
    page using the complex semantics of the browser layout algorithm.
    \par
    This paper introduces and formalizes \emph{modular layout proofs}. A
    modular layout proof splits a monolithic verification problem into smaller
    verification problems, one for each \emph{component} of a web page. Each
    \emph{component specification} can use rely/guarantee-style preconditions to make it
    verifiable independently of the rest of the page and enabling reuse across
    multiple pages. Modular layout proofs scale verification to pages an order
    of magnitude larger than those supported by previous approaches.
    \par
    We prototyped these techniques in a new proof assistant, Troika. In Troika,
    a proof author partitions a page into components and writes specifications
    for them. Troika then verifies the specifications, and uses those
    specifications to verify whole-page properties. Troika also enables the
    proof author to verify different component specifications with different
    verification tools, leveraging the strengths of each. In a case study, we
    use Troika to verify a large web page and demonstrate a speed-up of
    13--1469$\times$ over existing tools, taking verification time from hours to
    seconds. We develop a systematic approach to writing Troika proofs and
    demonstrate it on 8 proofs of properties from prior work to show that
    modular layout proofs are short, easy to write, and provide benefits over
    existing tools.",
  basefilename = "verify-layout-modular-oopsla2019",
  downloads = "https://cassius.uwplse.org/ Troika, VizAssert, and Cassius tools",
  category =  "User interfaces",
  csetags =   "pavpan,mernst,ztatlock,mernst-Verification,plse",
  summary =
   "The Troika tool modularizes previous work on layout verification,
   splitting a monolithic verification problem into independent parts,
   one for each component of a web page.",
}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%% 2020
%%%

@InProceedings{Ernst2020,
  author = 	 "Michael D. Ernst",
  title = 	 "How to be a better researcher than {I} am:  Lessons learned in a career of mistakes",
  crossref =  "ICSE2020",
  note = 	 "{ACM} SIGSOFT Outstanding Research Award talk",
  omitfromcv = "*",
}

@Article{BeschastnikhLXWBE2020,
  author = 	 "Beschastnikh, Ivan and Liu, Perry and Xing, Albert and Wang, Patty and Brun, Yuriy and Ernst, Michael D.",
  title = 	 "Visualizing Distributed System Executions",
  journal = 	 TOSEM,
  year = 	 2020,
  volume = 	 29,
  number = 	 2,
  pages = 	 "9:1--9:38",
  numpages = 38,
  month = 	 mar,
  abstract =
   "Distributed systems pose unique challenges for software
    developers. Understanding the system's communication topology and reasoning
    about concurrent activities of system hosts can be difficult. The standard
    approach, analyzing system logs, can be a tedious and complex process that
    involves reconstructing a system log from multiple hosts' logs, reconciling
    timestamps among hosts with non-synchronized clocks, and understanding what
    took place during the execution encoded by the log. This article presents a
    novel approach for tackling three tasks frequently performed during
    analysis of distributed system executions: (1) understanding the relative
    ordering of events, (2) searching for specific patterns of interaction
    between hosts, and (3) identifying structural similarities and differences
    between pairs of executions. Our approach consists of XVector, which
    instruments distributed systems to capture partial ordering information
    that encodes the happens-before relation between events, and ShiViz, which
    processes the resulting logs and presents distributed system executions as
    interactive time-space diagrams. Two user studies with a total of 109
    students and a case study with 2 developers showed that our method was
    effective, helping participants answer statistically significantly more
    system-comprehension questions correctly, with a very large effect size.",
  basefilename = "visualize-distributed-tosem2020",
  downloads =
   "https://bestchai.bitbucket.io/shiviz/ ShiViz;
    https://bestchai.bitbucket.io/shiviz-demo/ video demo of ShiViz;
    https://github.com/DistributedClocks XVector",
  category =  "Distributed systems",
  csetags = 	 "mernst,mernst-Distributed-systems,plse",
  summary =
   "This paper presents two dools to help developers comprehend distributed
    systems:  ShiVector to add vector timestamps to distributed system logs
    and ShiViz to visualize such logs as space-time diagrams.",
}



@InProceedings{KelloggRSSE2020,
  author = 	 "Martin Kellogg and Manli Ran and Manu Sridharan and Martin Sch{\"a}f and Michael D. Ernst",
  authorASCII = 	 "Martin Kellogg and Manli Ran and Manu Sridharan and Martin Schaef and Michael D. Ernst",
  authorASCII2 = 	 "Martin Kellogg and Manli Ran and Manu Sridharan and Martin Schaf and Michael D. Ernst",
  title = 	 "Verifying Object Construction",
  crossref =  "ICSE2020",
  pages = 	 "1447-1458",
  abstract =
   "In object-oriented languages, constructors often have a combination of
    required and optional formal parameters.  It is tedious and inconvenient
    for programmers to write a constructor by hand for each combination.  The
    multitude of constructors is error-prone for clients, and client code is
    difficult to read due to the large number of constructor arguments.
    Therefore, programmers often use design patterns that enable more flexible
    object construction---the builder pattern, dependency injection, or factory
    methods.
    \par
    However, these design patterns can be \emph{too} flexible: not all
    combinations of logical parameters lead to the construction of well-formed
    objects.  When a client uses the builder pattern to construct an object,
    the compiler does not check that a valid set of values was provided.
    Incorrect use of builders can lead to security vulnerabilities, run-time
    crashes, and other problems.
    \par
    This work shows how to statically verify uses of object construction, such
    as the builder pattern.  Using a simple specification language, programmers
    specify which combinations of logical arguments are permitted. Our
    compile-time analysis detects client code that may construct objects
    unsafely.  Our analysis is based on a novel special case of typestate
    checking, \emph{accumulation analysis}, that modularly reasons about
    accumulations of method calls. Because accumulation analysis does not
    require precise aliasing information for soundness, our analysis scales to
    industrial programs.  We evaluated it on over 9 million lines of code,
    discovering defects which included previously-unknown security
    vulnerabilities and potential null-pointer violations in heavily-used
    open-source codebases.  Our analysis has a low false positive rate and low
    annotation burden.
    \par
    Our implementation and experimental data are publicly available.",
  basefilename = "object-construction-icse2020",
  downloads =
    "https://docs.google.com/presentation/d/16aeJkvQqFqFkfs6Y1X6iwvGCsus37muEX5a7EwuGvEw/ slides (Google Slides);
     https://checkerframework.org/ implementation;
     https://doi.org/10.5281/zenodo.3634993 scripts and data",
  category =  "Verification",
  csetags =   "kelloggm,mernst,mernst-Verification,plse",
  summary =
   "This paper introduces accumulation analysis, a restricted form of
    typestate that requires no alias analysis.  It can verify correct
    use of the builder pattern and related patterns."
}


@InProceedings{LouisDBES2020,
  author = 	 "Annie Louis and Santanu Kumar Dash and Earl T. Barr and Michael D. Ernst and Charles Sutton",
  title = 	 "Where should I comment my code? A dataset and model for predicting locations that need comments",
  crossref =  "ICSENIER2020",
  pages = 	 "21-24",
  abstract =
   "Programmers should write code comments, but not on every line of code.
    We have created a machine learning model that suggests locations where a
    programmer should write a code comment.
    We trained it on existing
    commented code to learn locations that are chosen by developers.
    Once trained, the model can predict locations in new code.
    Our models achieved precision of 74\% and recall of 13\% in identifying
    comment-worthy locations.  This first success opens the door to future work, both in
    the new \emph{where-to-comment} problem and in guiding comment generation.
    Our code and data is available at
    \url{https://groups.inf.ed.ac.uk/cup/comment-locator/}.",
  basefilename = "predict-comments-icse2020",
  downloads = "https://groups.inf.ed.ac.uk/cup/comment-locator/ implementation and dataset",
  category =  "Natural language processing",
  csetags =   "mernst,mernst-Natural-language-processing,plse",
  summary =
   "This paper shows how to predict where programmers should write
   code comments.  Its models achieved precision of 74\% and recall of 13\%.",
}


@InProceedings{LamSOZEX2020,
  author = 	 "Wing Lam and August Shi and Reed Oei and Sai Zhang and Michael D. Ernst and Tao Xie",
  title = 	 "Dependent-test-aware regression testing techniques",
  crossref =  "ISSTA2020",
  pages = 	 "298-311",
  abstract =
   "Developers check their changes using regression testing
    techniques. Unfortunately, regression testing techniques suffer from flaky
    tests, which can both pass and fail when run multiple times on the same
    version of code and tests. While many types of flaky tests exist, one
    prominent type is dependent tests, which are tests that pass when run in
    one order but fail when run in another order.  Although dependent tests may
    cause flaky test failures, dependent tests can help developers run their
    tests faster. Since developers may still want dependent tests, we propose
    to make regression testing techniques dependent-test-aware to reduce flaky
    test failures.
    \par
    To understand the necessity of dependent-test-aware regression testing
    techniques, we conduct the first study on the impact of dependent tests on
    three regression testing techniques: test prioritization, test selection,
    and test parallelization. In particular, we implement 4 test
    prioritization, 6 test selection, and 2 test parallelization algorithms,
    and we evaluate them on 11 Java modules with dependent tests. When we run
    the orders produced by the traditional, dependent-test-unaware regression
    testing algorithms, 90\% of the human-written test suites with dependent
    tests have at least one flaky test failure, while 100\% of the
    automatically-generated test suites have at least one flaky test failure.
    \par
    We develop a general approach for enhancing regression testing algorithms
    to make them dependent-test-aware, and we apply our approach to enhance 12
    algorithms. Compared to traditional, unenhanced regression testing
    algorithms, the enhanced algorithms use provided test dependencies to
    produce different orders or orders with extra tests. Our evaluation shows
    that, in comparison to the orders produced by the unenhanced algorithms,
    the orders produced by the enhanced algorithms (1) have overall 65\% fewer
    flaky test failures due to dependent tests, and (2) may add extra tests but
    run only <1\% slower on average. Our results suggest that enhancing
    regression testing algorithms to be dependent-test-aware can substantially
    reduce flaky test failures with only a minor slowdown to run the tests.",
  basefilename = "dependent-tests-issta2020",
  downloads =
   "https://www.youtube.com/watch?v=YV9561AmNlU talk video (YouTube);
    https://github.com/TestingResearchIllinois/dependent-tests-impact implementation;
    https://sites.google.com/view/test-dependence-impact data",
  category =  "Testing",
  csetags = 	 "mernst,mernst-Testing,plse",
  summary =
   "Dependent tests are tests that pass when run in one order but fail
    when run in another order.  This paper presents a way to detect test
    dependencies, plus test prioritization, selection, and parallelization
    techniques that avoid violating the dependencies.",
}


@InProceedings{KelloggSTE2020,
  author = 	 "Martin Kellogg and Martin Sch{\"a}f and Serdar Tasiran and Michael D. Ernst",
  authorASCII1 = 	 "Martin Kellogg and Martin Schaf and Serdar Tasiran and Michael D. Ernst",
  authorASCII2 = 	 "Martin Kellogg and Martin Schaef and Serdar Tasiran and Michael D. Ernst",
  title = 	 "Continuous compliance",
  crossref =  "ASE2020",
  pages = 	 "511-523",
  abstract =
   "Vendors who wish to provide software or services to large corporations and
    governments must often obtain numerous certificates of compliance.  Each certificate asserts
    that the software satisfies a compliance regime, like SOC or the PCI DSS, to protect
    the privacy and security of sensitive data.
    The industry standard for obtaining a compliance certificate is an auditor
    manually auditing source code.  This approach is expensive, error-prone,
    partial, and prone to regressions.
    \par
    We propose \emph{continuous compliance}
    to guarantee that the codebase stays compliant on each code change
    using lightweight verification tools.
    Continuous compliance
    increases assurance and reduces costs.
    \par
    Continuous compliance is applicable to any source-code compliance requirement.  To
    illustrate our approach, we built verification tools for
    five common audit controls related to
    data security:
    cryptographically unsafe algorithms must not be used,
    keys must be at
    least 256 bits long, credentials must not be hard-coded into
    program text, HTTPS must always be used instead of HTTP, and
    cloud data stores must not be world-readable.
    \par
    We evaluated our approach in three ways.
    (1) We applied our tools to over 5
    million lines of open-source software.
    (2)  We compared our tools to other publicly-available tools for detecting
    misuses of encryption on a previously-published benchmark, finding that
    only ours are suitable for continuous
    compliance.
    (3) We deployed  a continuous compliance process
    at AWS, a large cloud-services company: we integrated verification tools into the compliance process
    (including auditors accepting their output as evidence)
    and ran them on over 68 million lines of code.
    Our tools and the data for the former two evaluations are publicly available.",
  basefilename = "continuous-compliance-ase2020",
  downloads =
   "https://doi.org/10.5281/zenodo.3976221 scripts and data;
    https://github.com/awslabs/aws-kms-compliance-checker KMS checker;
    https://github.com/awslabs/aws-crypto-policy-compliance-checker crypto checker;
    https://github.com/kelloggm/bucket-compliance-checker bucket checker;
    https://github.com/kelloggm/no-literal-checker no literal checker",
  category =  "Verification",
  csetags =   "kelloggm,mernst,mernst-Verification,plse",
  summary =
   "Formal verification is a good match for compliance requirements that are
    imposed by customers on vendors.  We deployed compliance verification tools
    in industry and ran case studies on over 60 million lines of code.",
}


@InProceedings{ChenGTEHFAJ2020,
  author = 	 "Chen, Yiqun T. and Gopinath, Rahul and Tadakamalla, Anita and Ernst, Michael D. and Holmes, Reid and Fraser, Gordon and Ammann, Paul and Just, Ren\'{e}",
  title = 	 "Revisiting the relationship between fault detection, test adequacy criteria, and test set size",
  crossref =  "ASE2020",
  pages = 	 "237-249",
  abstract =
   "The research community has long recognized a complex interrelationship
    between fault detection, test adequacy criteria, and test set
    size. However, there is substantial confusion about whether and how to
    experimentally control for test set size when assessing how well an
    adequacy criterion is correlated with fault detection and when comparing
    test adequacy criteria. Resolving the confusion, this paper makes the
    following contributions: (1) A review of contradictory analyses of the
    relationships between fault detection, test adequacy criteria, and test set
    size. Specifically, this paper addresses the supposed contradiction of
    prior work and explains why test set size is neither a confounding
    variable, as previously suggested, nor an independent variable that should
    be experimentally manipulated. (2) An explication and discussion of the
    experimental designs of prior work, together with a discussion of
    conceptual and statistical problems, as well as specific guidelines for
    future work. (3) A methodology for comparing test adequacy criteria on an
    equal basis, which accounts for test set size without directly manipulating
    it through unrealistic stratification. (4) An empirical evaluation that
    compares the effectiveness of coverage-based testing, mutation-based
    testing, and random testing. Additionally, this paper proposes
    probabilistic coupling, a methodology for assessing the representativeness
    of a set of test goals for a given fault and for approximating the
    fault-detection probability of adequate test sets.",
  basefilename = "test-set-size-ase2020",
  downloads =
   "https://docs.google.com/presentation/d/1ipwcUWZzHKkKbxFPYWkJ-z1OGdabBHF9-SVSPzF8RM8 slides (Google Slides)",
  category =  "Testing",
  csetags = 	 "mernst,rjust,mernst-Testing,plse",
  summary =
   "Test suite size has a big impact on test effectiveness.  How should
    experiments control for test suite size?  How do size and test adequacy
    (e.g., coverage) affect the fault detection power of a test suite?",
}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%% 2021
%%%

@TechReport{MudduluruWME2021:TR,
  author = 	 "Rashmi Mudduluru and Jason Waataja and Suzanne Millstein and Michael D. Ernst",
  title = 	 "Verifying determinism in sequential programs (extended version)",
  institution =  UWCSE,
  year = 	 2021,
  number = 	 "UW-CSE-2021-02-01",
  address = 	 UWCSEaddr,
  month = 	 feb,
  abstract =
   "When a program is nondeterministic, it is difficult to test and debug.
    Nondeterminism occurs even in sequential programs: for example,
    as a result of
    iterating over the elements of a hash table.
    \par
    We have created a type system that expresses determinism specifications
    in a program.
    The key ideas in the type system are type qualifiers for nondeterminism,
    order-nondeterminism, and determinism; type well-formedness rules to
    restrict collection types; and enhancements to polymorphism that
    improve precision when analyzing collection operations. While state-of-the-art
    nondeterminism detection tools rely on observing output from specific runs, our approach
    soundly verifies determinism at compile time.
    \par
    We implemented our type system for Java.
    Our type checker, the Determinism Checker, warns if a
    program is nondeterministic or verifies that the program is deterministic.
    In case studies of 90097 lines of code, the Determinism Checker
    found 87
    previously-unknown nondeterminism errors, even in programs that had been heavily
    vetted by developers who were greatly concerned about nondeterminism errors.
    In experiments, the Determinism Checker found all of the
    non-concurrency-related nondeterminism that was found by
    state-of-the-art dynamic approaches for detecting flaky tests.",
  basefilename = "determinism-tr20210201",
  supersededby = "MudduluruWME2021 An extended version",
  csetags = 	 "rashmi4,jwaataja,smillst,mernst,mernst-Verification,plse",
  summary =
   "This paper presents a type system that captures whether a value is
    deterministic (the same across runs), nondeterministic, or
    order-nondeterministic (each collection has the same contents across
    runs, but possibly in a different order).",
}


@InProceedings{MudduluruWME2021,
  author = 	 "Rashmi Mudduluru and Jason Waataja and Suzanne Millstein and Michael D. Ernst",
  title = 	 "Verifying determinism in sequential programs",
  crossref =  "ICSE2021",
  pages = 	 "37-49",
  abstract =
   "When a program is nondeterministic, it is difficult to test and debug.
    Nondeterminism occurs even in sequential programs: e.g.,
    by
    iterating over the elements of a hash table.
    \par
    We have created a type system that expresses determinism specifications
    in a program.
    The key ideas in the type system are type qualifiers for nondeterminism,
    order-nondeterminism, and determinism; type well-formedness rules to
    restrict collection types; and enhancements to polymorphism that
    improve precision when analyzing collection operations. While state-of-the-art
    nondeterminism detection tools rely on observing output from specific runs, our approach
    soundly verifies determinism at compile time.
    \par
    We implemented our type system for Java.
    Our type checker, the Determinism Checker, warns if a
    program is nondeterministic or verifies that the program is deterministic.
    In case studies of 90097 lines of code, the Determinism Checker
    found 87
    previously-unknown nondeterminism errors, even in programs that had been heavily
    vetted by developers who were greatly concerned about nondeterminism errors.
    In experiments, the Determinism Checker found all of the
    non-concurrency-related nondeterminism that was found by
    state-of-the-art dynamic approaches for detecting flaky tests.",
  basefilename = "determinism-icse2021",
  category =  "Verification",
  downloads =
   "https://homes.cs.washington.edu/~mernst/pubs/determinism-tr210201.pdf extended version (PDF);
    https://github.com/t-rasmud/checker-framework/tree/nondet-checker implementation;
    https://doi.org/10.5281/zenodo.4536285 experimental data",
  OPTdownloadsnonlocal = "",
  csetags = 	 "rashmi4,jwaataja,smillst,mernst,mernst-Verification,plse",
  summary =
   "This paper presents a type system that captures whether a value is
    deterministic (the same across runs), nondeterministic, or
    order-nondeterministic (each collection has the same contents across
    runs, but possibly in a different order).",
}


@InProceedings{KelloggSSE2021,
  author = 	 "Martin Kellogg and Narges Shadab and Manu Sridharan and Michael D. Ernst",
  title = 	 "Lightweight and modular resource leak verification",
  crossref =  "FSE2021",
  pages = 	 "181--192",
  doi = {10.1145/3468264.3468576},
  abstract =
   "A resource leak occurs when a program allocates a resource, such as a socket
    or file handle, but fails to deallocate it.  Resource leaks cause resource
    starvation, slowdowns, and crashes.  Previous techniques to prevent resource
    leaks are either unsound, imprecise, inapplicable to existing code, slow, or a
    combination of these.
    \par
    Static detection of resource leaks requires checking that de-allocation
    methods are always invoked on relevant objects before they become unreachable.
    Our key insight is that leak detection can be reduced to an accumulation
    problem, a class of typestate problems amenable to sound and modular checking
    without the need for a heavyweight, whole-program alias analysis.  The
    precision of an accumulation analysis can be improved by computing targeted
    aliasing information, and we augmented our baseline checker with three such
    novel techniques:  a lightweight ownership transfer system; a specialized
    resource alias analysis; and a system to create a fresh obligation when a
    non-final resource field is updated.
    \par
    Our approach occupies a unique slice of the design space: it is sound and runs
    relatively quickly (taking minutes on programs that a state-of-the-art
    approach took hours to analyze).  We implemented our techniques for Java in an
    open-source tool called the Resource Leak Checker.  The Resource Leak Checker
    revealed 49 real resource leaks in widely-deployed software.  It scales well,
    has a manageable false positive rate (comparable to the high-confidence
    resource leak analysis built into the Eclipse IDE), and imposes only a small
    annotation burden (1/1500 LoC) for developers.",
  basefilename = "resource-leak-esecfse2021",
  downloads =
   "https://docs.google.com/presentation/d/1MBBVh0wbaQnlxKwsPwMPEFVIMaH2tj6NghN9NYgnaZo slides (Google Slides);
    https://www.youtube.com/watch?v=bY5K3kRg3aw talk video (YouTube);
    https://checkerframework.org/ implementation;
    https://doi.org/10.5281/zenodo.4902321 scripts and data",
  TODOdownloadsnonlocal = "*",
  category =  "Verification",
  csetags =   "kelloggm,mernst,mernst-Verification,plse",
  summary =
   "This paper presents a modular approach to detecting resource leaks that does
    not require a heavy-weight whole-program analysis.  The approach is sound,
    is applicable to existing code, and is easy for developers to use.",
}


@InProceedings{ZhangFEPD2021,
  author = 	 "Zhen Zhang and Yu Feng and Michael D. Ernst and Sebastian Porst and Isil Dillig",
  title = 	 "Checking conformance of applications against {GUI} policies",
  crossref =  "FSE2021",
  pages = 	 "95-106",
  abstract =
   "A good graphical user interface (GUI) is crucial for an application's usability,
    so vendors and regulatory agencies increasingly place restrictions on how GUI
    elements should appear to and interact with users. Motivated by this concern,
    this paper presents a new technique (based on static analysis) for checking
    conformance between (Android) applications and GUI policies expressed in a
    formal specification language. In particular, this paper (1) describes a
    specification language for formalizing GUI policies, (2) proposes a new program
    abstraction called an \emph{event-driven layout forest}, and (3) describes a
    static analysis for constructing this abstraction and checking it against a GUI
    policy. We have implemented the proposed approach in a tool called Venus, and
    we evaluate it on 2361 Android applications and 17 policies. Our evaluation
    shows that Venus can uncover malicious applications that perform ad fraud and
    identify violations of GUI design guidelines and GDPR laws.",
  basefilename = "gui-policies-esecfse2021",
  downloads =
   "https://docs.google.com/presentation/d/1CsPMaomfsL53KON1nWfI3vVN8bKmzLMJJ0xUDysmj5g/ slides (Google Slides);
    https://github.com/izgzhen/ui-checker implementation",
  TODOdownloadsnonlocal = "*",
  category =  "Security,Mobile applications",
  csetags = "zgzhen,mernst,mernst-Security,plse",
  summary =
   "Deceptive GUIs can cause interactions that users do not intend, and badly
    designed GUIs can reduce usability. This paper shows how to analyze an
    Android app to ensure that it obeys GUI best practices.",
}


@Article{BlasiGEPC2021,
  author = 	 "Arianna Blasi and Alessandra Gorla and Michael D. Ernst and Mauro Pezz{\`e} and Antonio Carzaniga",
  authorASCII = 	 "Arianna Blasi and Alessandra Gorla and Michael D. Ernst and Mauro Pezze and Antonio Carzaniga",
  title = 	 "{MeMo}: Automatically identifying metamorphic relations in {Javadoc} comments for test automation",
  journal = 	 JSS,
  year = 	 "2021",
  volume = 	 "181",
  pages = 	 "111041:1--13",
  month = 	 nov,
  abstract =
   "Software testing depends on effective oracles. Implicit oracles, such as
    checks for program crashes, are widely applicable but narrow in scope.
    Oracles based on formal specifications can reveal application-specific
    failures, but specifications are expensive to obtain and maintain.
    Metamorphic oracles are somewhere in-between.  They test equivalence among
    different procedures to detect semantic failures. Until now, the
    identification of metamorphic relations has been a manual and expensive
    process, except for few specific domains where automation is possible. We
    present MeMo, a technique and a tool to automatically derive metamorphic
    equivalence relations from natural language documentation, and we use such
    metamorphic relations as oracles in automatically generated test cases. Our
    experimental evaluation demonstrates that 1) MeMo can effectively and
    precisely infer equivalence metamorphic relations, 2) MeMo complements
    existing state-of-the-art techniques that are based on dynamic program
    analysis, and 3) metamorphic relations discovered with MeMo effectively detect
    defects when used as test oracles in automatically-generated or
    manually-written test cases.",
  basefilename = "identify-metamorphic-jss-2021",
  downloads = "https://github.com/ariannab/MeMo implementation",
  category =  "Natural language processing",
  csetags = 	 "mernst,mernst-Natural-language-processing,plse",
  summary =
   "A metamorphic relation expresses that two expressions have the same value.
    MeMo translates natural-language documentation into metamorphic relations.",
  doi = {https://doi.org/10.1016/j.jss.2021.111041},
}



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%% 2022
%%%

@InProceedings{KelloggSSE2022,
  author = 	 "Martin Kellogg and Narges Shadab and Manu Sridharan and Michael D. Ernst",
  title = 	 "Accumulation analysis",
  crossref =  "ECOOP2022",
  pages = 	 "10:1-10:31",
  doi =	{10.4230/DARTS.8.2.22},
  abstract =
   "A typestate specification indicates which
    behaviors of an object are permitted in each of the object's states.
    In the general case, soundly checking a typestate specification
    requires precise information about aliasing
    (i.e.,  an alias or pointer analysis),
    which is computationally expensive.
    This requirement has hindered the adoption of sound typestate analyses
    in practice.
    \par
    This paper identifies \emph{accumulation typestate specifications},
    which are the subset of typestate specifications that
    can be soundly checked without any information about aliasing.
    An accumulation typestate specification can be checked instead
    by an accumulation analysis: a simple, fast
    dataflow analysis that conservatively approximates the
    operations that have been performed on an object.
    \par
    This paper formalizes the notions of accumulation analysis and
    accumulation typestate specification. It proves
    that accumulation typestate specifications are exactly those typestate specifications
    that can be checked soundly without aliasing information.
    Further, 41\% of the typestate specifications that appear in the
    research literature are accumulation typestate specifications.",
  basefilename = "accumulation-analysis-ecoop2022",
  downloads =
   "https://docs.google.com/presentation/d/1cEk5wH9L1a5a9bXof3BmA7DN6Nwx9NIVU5j5UqCQ2iE slides (Google Slides);
    https://checkerframework.org/ implementation;
    https://doi.org/10.5281/zenodo.5771196 artifact",
  category =  "Verification",
  csetags =   "kelloggm,mernst,mernst-Verification,plse",
  summary =
   "This paper proves that accumulation typestate specifications can be
    checked soundly without aliasing information. Further, 41\% of the
    typestate specifications in the research literature are accumulation
    typestate specifications.",
}


@Article{KelloggSSE2022:artifact,
  author = 	 "Martin Kellogg and Narges Shadab and Manu Sridharan and Michael D. Ernst",
  title = 	 "Accumulation analysis (artifact)",
  journal =	 "DARTS, Dagstuhl Artifacts Series",
  year = 	 2022,
  volume = 	 8,
  number = 	 2,
  pages = 	 "22:1-22:3",
  month = 	 jun,
  address = 	 "Berlin, Germany",
  abstract =
   "This artifact contains the data and analysis supporting the literature
    survey in section 4 of [4]. In our literature survey, we examined 187
    papers from the literature that mention ``typestate'' and analyzed the
    typestate specifications they contained to determine whether or not they
    are accumulation typestate specifications.
    \par
    Our purpose in doing this literature survey was to determine whether
    typestate FSMs were accumulation or not. However, we believe that the
    collection of typestate automata in typestates.pdf might be useful to
    anyone interested in the sort of typestate automata that appear in the
    literature. If we had had access to such a collection (gathered for a
    different purpose), our classification of whether these typestate automata
    were accumulation would have been much simpler. Anyone interested in
    properties of typestate automata can re-use our work.",
  basefilename = "accumulation-analysis-ecoop2022-artifact",
  downloads = "https://checkerframework.org/ implementation;
               https://drops.dagstuhl.de/opus/volltexte/2022/16220/artifact/DARTS-8-2-22-artifact-429b8a9421df64399b328dfa1e075a9d.zip artifact",
  category =  "Verification",
  csetags =   "kelloggm,mernst,mernst-Verification,plse",
  summary =
   "This short paper discusses a literature review of research on
    typestate analysis, and provides the experimental data.",
}


@InProceedings{BlasiGEP2022,
  author = 	 "Arianna Blasi and Alessandra Gorla and Michael D. Ernst and Mauro Pezz{\`e}",
  authorASCII = 	 "Arianna Blasi and Alessandra Gorla and Michael D. Ernst and Mauro Pezze",
  authorNONASCII = 	 "Arianna Blasi and Alessandra Gorla and Michael D. Ernst and Mauro Pezzè",
  title = 	 "{Call Me Maybe}: Using {NLP} to automatically generate unit test cases respecting temporal constraints",
  crossref =  "ASE2022",
  pages = 	 "1-11",
  abstract =
   "A class may need to obey temporal constraints in order to function
    correctly.  For example, the correct usage protocol for an iterator is
    to always check whether there is a next element before asking for it;
    iterating over a collection when there are no items left leads to a
    \emph{NoSuchElementException}.  Automatic test case generation tools
    such as Randoop and EvoSuite do not have any notion of these temporal
    constraints. Generating test cases by randomly invoking methods on a
    new instance of the class under test may raise run time exceptions
    that do not necessarily expose software faults, but are rather a
    consequence of violations of temporal properties.
    \par
    This paper presents \emph{CallMeMaybe}, a novel technique that uses
    natural language processing to analyze Javadoc comments to identify
    temporal constraints. This information can guide a test case generator
    towards executing sequences of method calls that respect the temporal
    constraints. Our evaluation on 73 subjects from seven popular Java
    systems shows that \emph{CallMeMaybe} achieves a precision of 83\% and
    a recall of 70\% when translating temporal constraints into Java
    expressions.  For the two biggest subjects, the integration with
    Randoop flags 11,818 false alarms and enriches 12,024 correctly
    failing test cases due to violations of temporal constraints with
    clear explanation that can help software developers.",
  basefilename = "nlp-unittest-temporal-ase2022",
  downloads = "https://github.com/ariannab/callmemaybe implementation & replication package",
  category =  "Natural language processing",
  csetags = 	 "mernst,mernst-Natural-language-processing,plse",
  summary =
   "This paper presents an NLP technique that analyzes code comments to identify
    temporal constraints such as ``the thread should be started after setting
    the daemon'', and it converts them into executable assertions.",
}


@Book{ErnstProgramAnalysis2022,
  author = 	 "Michael D. Ernst",
  title = 	 "Notes on Program Analysis",
  publisher = 	 "\url{https://homes.cs.washington.edu/~mernst/pubs/program-analysis-book.pdf}",
  year = 	 2022,
  month = 	 sep,
  basefilename = "program-analysis-book",
  downloads = "https://homes.cs.washington.edu/~mernst/pubs/program-analysis-book.pdf PDF",
  category =  "Static analysis",
  csetags = "mernst,mernst-Static-analysis,plse",
  summary =
   "This book is an introduction to program analysis.  It covers abstract
    interpretation (dataflow analysis), testing, and other topics. It is
    appropriate for self-study or for use in a graduate or advanced
    undergraduate class.",
}


@Article{ErnstOptionalType2022,
  author = 	 "Michael D. Ernst",
  title = 	 "Nothing is better than the {Optional} type. {Really}. {Nothing} is better.",
  journal = 	 "Java Magazine",
  year = 	 2022,
  month = 	 dec,
  basefilename = "optional-type-javamagazine-2022",
  downloadsnonlocal =
   "https://homes.cs.washington.edu/~mernst/advice/nothing-is-better-than-optional.html original version;
    https://blogs.oracle.com/javamagazine/post/optional-class-null-pointer-drawbacks Java Magazine version",
  category =  "Static analysis",
  csetags = "mernst,mernst-Static-analysis,plse",
  summary =
   "The blogosphere is full of claims that the Optional class solves the
    problem of null pointer exceptions. This article explains why those claims
    are not true, and a better way to prevent null pointer exceptions.",
}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%% 2023
%%%


@InProceedings{KelloggDNAE2023,
  author = 	 "Martin Kellogg and Daniel Daskiewicz and Loi Ngo Duc Nguyen and Muyeed Ahmed and Michael D. Ernst",
  title = 	 "Pluggable type inference for free",
  crossref =  "ASE2023",
  NEEDpages = 	 "*",
  abstract =
   "A pluggable type system extends a host programming language with type
    qualifiers.  It lets programmers write types like
    \texttt{unsigned int}, \texttt{secret string}, and \texttt{nonnull object}.
    Typechecking with pluggable types detects
    and prevents more errors than the host type system.  However,
    programmers must write type qualifiers; this is the biggest obstacle to use of
    pluggable types in practice.  Type inference can solve this problem.
    Traditional approaches to type inference are type-system-specific:  for
    each new pluggable type system, the type inference algorithm must be
    extended to build and then solve a system of constraints corresponding to
    the rules of the underlying type system.
    \par
    We propose a novel type inference algorithm that can infer type qualifiers
    for \emph{any} pluggable type system with little to no new
    type-system-specific code---that is, ``for free''.  The key insight is that
    extant practical pluggable type systems are flow-sensitive and therefore
    already implement local type inference.  Using this insight, we can derive
    a global inference algorithm by re-using existing implementations of local
    inference.  Our algorithm runs iteratively in rounds.  Each round uses the
    results of local type inference to produce summaries (specifications) for
    procedures and fields. These summaries enable improved inference throughout
    the program in subsequent rounds.  The algorithm terminates when the
    inferred summaries reach a fixed point.
    \par
    In practice, many pluggable type systems are built on frameworks. By
    implementing our algorithm \emph{once}, at the framework level, it can be
    reused by \emph{any} typechecker built using that framework. Using that
    insight, we have implemented our algorithm for the open-source Checker
    Framework project, which is widely used in industry and on which dozens of
    specialized pluggable typecheckers have been built.  In experiments with
    11 distinct pluggable type systems and 12 projects,
    our algorithm reduced, by 45\% on average, the number
    of warnings that developers must resolve by writing annotations.",
  basefilename = "pluggable-inference-ase2023",
  downloads = "https://checkerframework.org/ implementation",
  category = "Static analysis",
  csetags = "mernst,mernst-Static-analysis,plse",
  summary =
   "This paper describes a type inference framework.  Given a pluggable
    type-checker implementation, the framework automatically creates a type
    inference tool.",
}



@Article{ShadabGTEKLLS2023,
  author = 	 "Shadab, Narges and Gharat, Pritam and Tiwari, Shrey and Ernst, Michael D. and Kellogg, Martin and Lahiri, Shuvendu and Lal, Akash and Sridharan, Manu",
  title = 	 "Inference of resource management specifications",
  journal = 	 PACMPL,
  year = 	 2023,
  volume = 	 7,
  number = 	 "OOPSLA2, article \#282",
  pages = 	 "1705-1728",
  month = 	 oct,
  abstract =
   "A resource leak occurs when a program fails to free some finite resource
    after it is no longer needed. Such leaks are a significant cause of
    real-world crashes and performance problems.
    We recently
    proposed an approach to prevent resource leaks based on checking
    \textit{resource management specifications}.
    A resource management specification expresses how the program allocates
    resources, passes them around, and releases them; it also tracks
    the ownership relationship between objects and resources, and
    aliasing relationships between objects.
    While this specify-and-verify approach has several advantages compared to
    prior techniques, the need to manually write annotations presents a
    significant barrier to its practical adoption.
    \par
    This paper presents a novel technique to automatically infer a resource
    management specification for a program, broadening the applicability of
    specify-and-check verification for resource leaks.  Inference in this domain is
    challenging because resource management specifications differ significantly in
    nature from the types that most inference techniques target.  Further, for
    practical effectiveness, we desire a technique that can infer the resource
    management specification intended by the developer, even in cases when the code
    does not fully adhere to that specification.  We address these challenges
    through a set of inference rules carefully designed to capture real-world coding
    patterns, yielding an effective fixed-point-based inference algorithm.
    \par
    We have implemented our inference algorithm in two different systems,
    targeting programs written in Java and C\#.
    In an experimental evaluation,
    our technique inferred 85.5\%
    of the annotations that programmers had written
    manually for the benchmarks.
    Further, the verifier issued nearly the same rate of false alarms with the
    manually-written and automatically-inferred annotations.",
  basefilename = "resource-inference-oopsla2023",
  downloads = "https://checkerframework.org/ implementation",
  category =  "Static analysis",
  csetags = "mernst,mernst-Static-analysis,plse",
  summary =
   "This paper proposes an optimistic analysis to infer specifications about how
    a program uses and releases resources.  Inference reduces the programmer
    burden to use a specify-and-verify approach to preventing resource leaks.",
}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%% 2024
%%%


@InProceedings{SamhiJBEK2024,
  author = 	 "Jordan Samhi and Rene Just and Tegawend{\'e} F. Bissyand{\'e} and Michael D. Ernst and Jacques Klein",
  authorASCII = 	 "Jordan Samhi and Rene Just and Tegawende F. Bissyande and Michael D. Ernst and Jacques Klein",
  authorNONASCII = 	 "Jordan Samhi and Rene Just and Tegawendé F. Bissyandé and Michael D. Ernst and Jacques Klein",
  title = 	 "Call graph soundness in Android static analysis",
  crossref =  "ISSTA2024",
  NEEDpages = 	 "*",
  abstract =
   "Static analysis is sound in theory, but an implementation may unsoundly
    fail to analyze all of a program's code. Any such omission is a serious
    threat to the validity of the tool's output. Our work is the first to
    measure the prevalence of these omissions. Previously, researchers and
    analysts did not know what is missed by static analysis, what sort of code
    is missed, or the reasons behind these omissions. To address this gap, we
    ran 13 static analysis tools and a dynamic analysis on 1000 Android
    apps. Any method in the dynamic analysis but not in a static analysis is an
    unsoundness.
    \par
    Our findings include the following. (1) Apps built around external
    frameworks challenge static analyzers. On average, the 13 static analysis
    tools failed to capture 61\% of the dynamically-executed methods. (2) A high
    level of precision in call graph construction is a synonym for a high level
    of unsoundness.; (3) No existing approach significantly improves static
    analysis soundness. This includes those specifically tailored for a given
    mechanism, such as DroidRA to address reflection. It also includes
    systematic approaches, such as EdgeMiner, capturing all callbacks in the
    Android framework systematically. (4) Modeling entry point methods
    challenges call graph construction which jeopardizes soundness.",
  basefilename = "callgraph-soundness-issta2024",
  downloads = "https://anonymous.4open.science/r/Call-Graph-Soundness-in-Android-Static-Analysis-2CD7 artifacts",
  category =     "Static analysis,Mobile applications",
  csetags = 	 "mernst,rjust,mernst-Static-analysis,plse",
  summary =
   "We analyzed 13 static analyzers for Android code. They are very unsound: they
    failed to analyze 61\%, on average, of the dynamically-executed methods.
    Tools were bad at discovering entry points, higher-precision tools were most
    unsound.",
}


@InProceedings{YooEJ2024,
  author = 	 "James Yoo and Michael D. Ernst and Ren\'e Just",
  authorASCII =  "James Yoo and Michael D. Ernst and Ren\'e Just",
  authorNONASCII = "James Yoo and Michael D. Ernst and René Just",
  title = 	 "Verifying the option type with rely-guarantee reasoning",
  crossref =  "ASE2024",
  NEEDpages = 	 "*",
  abstract =
   "Many programming languages include an implementation of the
    option type, which encodes the absence or presence of values.
    Incorrect use of the option type results in run-time errors, and unstylistic
    use results in unnecessary code. Researchers and practitioners have
    tried to mitigate the pitfalls of the option type, but have yet to
    evaluate tools for enforcing correctness and good style.
    \par
    To address problems of correctness, we developed two modular
    verifiers that cooperate via a novel form of rely-guarantee
    reasoning; together, they verify use of the option type. We implemented
    them in Axiom, an open-source static verifier. Axiom is the first
    verifier for the option type based on a sound theory --- that is, it
    issues a compile-time guarantee of the absence of run-time errors
    related to misuse of the option type. We then conducted the first
    mechanized study of tools that aim to prevent run-time errors related
    to the option type. We compared the performance of Axiom,
    SpotBugs, Error Prone, and IntelliJ IDEA over 1M non-comment,
    non-blank lines of code. Axiom found 13 previously-undiscovered
    bugs (a superset of those found by all other tools) and had the
    highest precision at 93\%.
    \par
    To address problems of style, we conducted a literature review
    of best practices for the option type. We discovered widely varying
    opinions about proper style. We implemented linting rules in Axiom
    and discovered hundreds of violations of the style recommended
    by Oracle, including in 11\% of JDK files that use Optional. Some
    of these were objectively bad code, and others reflected different
    styles.",
  basefilename = "verify-optional-ase2024",
  downloads = "https://checkerframework.org/ implementation",
  category =  "Verification",
  csetags = 	 "jmsy,mernst,rjust",
  summary =
   "This paper presents the first system to make the option type both concise (no
    boilerplate code or unnecessary checks) and correct (no run-time errors). Our
    tool is sound and has 93\% precision. It found 13 new bugs in open-source code.",
}




@TechReport{ScheschFYRE2024:TR,
  author = 	 "Benedikt Schesch and Ryan Featherman and Kenneth J. Yang and Ben R. Roberts and Michael D. Ernst",
  title = 	 "Evaluation of Version Control Merge Tools (Appendix)",
  institution =  UWCSE,
  year = 	 2024,
  number = 	 "UW-CSE-24-09-01",
  address = 	 UWCSEaddr,
  month = 	 sep,
  abstract =  "This appendix accompanies the ASE 2024 paper ``Evaluation of
                  Version Control Merge tools''.",
  basefilename = "merge-evaluation-ase2024-appendix",
  supersededby = "ScheschFYRE2024 An appendix",
  category =  "Software engineering",
  csetags = 	 "mernst",
  summary =
   "This paper gives about 75 examples of merge tool output, highlighting the
   strengths and weaknesses of different tools.  It is an appendix to the ASE
   2024 paper ``Evaluation of Version Control Merge tools''.",
}

@InProceedings{ScheschFYRE2024,
  author = 	 "Benedikt Schesch and Ryan Featherman and Kenneth J. Yang and Ben R. Roberts and Michael D. Ernst",
  title = 	 "Evaluation of version control merge tools",
  crossref =  "ASE2024",
  NEEDpages = 	 "*",
  abstract =
   "A version control system, such as Git, requires a way to integrate changes
    from different developers or branches. Given a merge scenario, a merge tool
    either outputs a clean integration of the changes, or it outputs a conflict
    for manual resolution.  A clean integration is correct if it preserves
    intended program behavior, and is incorrect otherwise (e.g., if it causes a
    test failure).  Manual resolution consumes valuable developer time, and
    correcting a defect introduced by an incorrect merge is even more costly.
    \par
    New merge tools have been proposed, but they have not yet been evaluated
    against one another.  Prior evaluations do not properly distinguish between
    correct and incorrect merges, are not evaluated on a realistic set of merge
    scenarios, and/or do not compare to state-of-the-art tools.  We have
    performed a more realistic evaluation.  The results differ significantly
    from previous claims, setting the record straight and enabling better
    future research.  Our novel experimental methodology combines running test
    suites, examining merges on deleted branches, and accounting for the cost
    of incorrect merges.
    \par
    Based on these evaluations, we created a merge tool that outperforms all
    previous tools under most assumptions.  It handles the most common merge
    scenarios in practice.",
  basefilename = "merge-evaluation-ase2024",
  downloads = "https://github.com/plume-lib/merging implementation",
  category =  "Software engineering",
  csetags = 	 "mernst",
  summary =
   "This paper proposes a new methodology for evaulating merge tools that
    accounts for the cost of incorrect merges. The paper evaluates previous
    tools and presents a new tool that outperforms all previous tools.",
}



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%% 2025
%%%




@InProceedings{PengZECD2025,
  author = 	 "Haoran Peng and Yu Zhang and Michael D. Ernst and Jinbao Chen and Boyao Ding",
  title = 	 "GoFree: Reducing garbage collection via compiler-inserted freeing",
  crossref =  "CGO2025",
  NEEDpages = 	 "*",
  OPTabstract =
   "In a memory-managed programming language, programmers allocate memory by
    creating new objects, but programmers never free memory. A garbage
    collector periodically reclaims memory used by unreachable objects. As an
    optimization based on escape analysis, some memory can be freed explicitly
    by instructions inserted by the compiler. This optimization reduces the
    cost of garbage collection, without changing the programming model.
    \par
    We designed and implemented this explicit freeing optimization for the Go
    language. We devised a new escape analysis that is both powerful and fast
    ($O(n^2)$ time). Our escape analysis identifies short-lived heap objects
    that can be safely explicitly deallocated. We also implemented a freeing
    primitive that is safe for use in concurrent environments.
    \par
    We evaluated our system, GoFree, on 6 open-source Go programs. GoFree did
    not observably slow down compilation.  At run time, GoFree deallocated on
    average 14.1\% of allocated heap memory. It reduced GC frequency by 7.3\%,
    GC time by 13.0\%, wall-clock time by 2.0\%, and heap size by 3.6\%.",
  basefilename = "explicit-free-cgo2025",
  OPTdownloads = "",
  OPTdownloadsnonlocal = "",
  category =     "Miscellaneous",
  csetags = 	 "hrpeng,mernst,mernst-Miscellaneous,plse",
  summary =
    "Explicit freeing of memory is more efficient than garbage collection, but
     it is tedious and error-prone.  Our system GoFree automatically inserts
     free operations where it is legal to do so, overall reducing run time.",
}


%% When I add here at the bottom of the file, also post a PLSE news item.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%% To appear, no date known yet
%%%



% Note that this is the end of the "To appear, no date known yet" section;
% if a date is known, put the paper one section earlier in the file.




% LocalWords:  inproceedings typechecking booktitle apr basefilename pp RSA UW
% LocalWords:  mltypechecking mitacmug ML's nonPAG MastersThesis jun co ESEC NY
% LocalWords:  miteecs MITaddr rpsmodel ernst bsthesis Vuillemin ErnstF ArtziE
% LocalWords:  InProceedings Flinchbaugh OPTcrossref OPTkey OPTeditor dataflow
% LocalWords:  OPTvolume OPTnumber OPTseries OPTpages AAAI OPTpublisher Shay oo
% LocalWords:  OPTorganization CSC SIUL OPTannote curvematch aaai com Artzi Guo
% LocalWords:  ridgelines Flinchbaugh's flinchbaugh Quotational Boolos javari
% LocalWords:  Quine Paulo Leonardi San TechReport AIV supersededby min GuoME
% LocalWords:  Ingari Kapor Lemberg Cullinet ADAPSO ipcolloq ps sep EDB Fjalar
% LocalWords:  Leiserson omitfromcv annote ftp ErnstY Yuval Heraclitean SaffAPE
% LocalWords:  codetext plaintext decryptor Elwyn Berlekamp subgames DS Eclat's
% LocalWords:  endgames Schinsky WeiseCES Weise Bjarne Steensgaard jan VSTTE fn
% LocalWords:  CFG ASU CLZ FOW AWZ RWZ KRS Dha SSA vdg popl TR MSR WA TschantzE
% LocalWords:  NOTsupersededby heraclitean tr encryptor SlicingTR proc mindset
% LocalWords:  subcategory OPTnote OPTomitfromcv longjmp ir UMAP konane vstte
% LocalWords:  ppt PowerPoint aug InCollection Santambrogio Misc YuvalE pdf ase
% LocalWords:  howpublished dec ijcai addr Kautz satcompile ErnstKC CSE CTAS rc
% LocalWords:  Kaplan ecoop ErnstCGN Cockrell Griswold UWCSE TSE icse DemskyER
% LocalWords:  Czeisler nov ErnstGKN Yoshio Kataoka mytree PDF ErnstBN FreeCiv
% LocalWords:  downloadsnonlocal Badros tosem PhdThesis phdthesis feb GuoPME
% LocalWords:  TSEnote Gries's tse ICSEpanel Gorlick se NimmerE RV ESC ErnstP
% LocalWords:  Nimmer rv jul usesDaikon KataokaEGN ICSM icsm OPTauthor tutdate
% LocalWords:  StreckenbachS CV url OPTaddress OPTedition oct ISSTA fse SCP scp
% LocalWords:  MITLCS issta DodooDLE Nii Dodoo NOTEaboutbasefilename dm daikon
% LocalWords:  alsosee NeWinEL NeWinE Toh IOA WilmerE Bultena Ruskey rl OLDnote
% LocalWords:  Combin supercomposite graycodes IEEETSE Cpp Cpp's VMCAI dAPMXE
% LocalWords:  NeWinEGKL Dilsun Paxos STTT simexecution vmcai Kirli ADT Marinov
% LocalWords:  HarderME Mellen testsuite DonovanE DonovanKTE java util d'Amorim
% LocalWords:  parameterisation GJ generalisation generalisations Burdy testgen
% LocalWords:  BurdyEtAl Yoonsik Cheon Cok Kiniry Rustan Leino JML NIII Randoop
% LocalWords:  Nijmegen jml trr smartcards WODA OMITeditor woda SEN LCS ErnstLP
% LocalWords:  staticdynamic FMICS fmics McCamantE DodooLE SaffE ISSRE WSMATE
% LocalWords:  issre ThesisTR mccamant LinE underperforms BrunE Yuriy NEEDmonth
% LocalWords:  Brun machlearn sttt ETX conttest plugin etx workflow ct subst
% LocalWords:  LOSTdownloadsnonlocal BirkaE Birka NEEDpages oopsla Kie wsmate
% LocalWords:  Javari interoperable const Javari's readonly DonovanKE KiezunETF
% LocalWords:  usesDaikonAsTestSubject PachecoE Eclat underreview un preprocess
% LocalWords:  Tschantz Kiezun PerkinsE savcbs OPTmonth JML's TACAS ASE Fuhrer
% LocalWords:  NeWinEG OPThowpublished MeghaniE Samir Meghani ErnstC NEEDnumber
% LocalWords:  Chapin Groupthink groupthink NOTomitfromcv WilliamsTE sortedness
% LocalWords:  Thies kLOC RazES Orna Raz outlier hotswapping assignability AFRL
% LocalWords:  interoperability nodownloads postprocessing ErnstPGLMPTX Glasser
% LocalWords:  OMIThowpublished DemskyEGMPR overfitting ErnstPGMPTX authorASCII
% LocalWords:  NEEDdownloadsnonlocal NEEDvolume NOTYETdownloadsnonlocal RinardE
% LocalWords:  PachecoLPBE composable ArtziEGKPP dAmorimPMXE MITCSAIL gen MTOOS
% LocalWords:  PachecoLEB MSRaddr ArtziEGK ArtziKGE mtoos CustomTypeQualifiers
% LocalWords:  AnnotationsOnJavaTypes AnnotationIndexFile DSpace Mehdi Jazayeri
% LocalWords:  Paola Inverardi LNCS KimE FindBugs Jlint PMD Columba jEdit msr
% LocalWords:  ZibinPAKE Zibin Potanin ReadOnly PLAS infoflow plas Lucene PapiE
% LocalWords:  CorreaQE refimmut NonNull typequals Randoop's pacheco randoop
% LocalWords:  PapiACPE KimAE ReCrash ReCrashJ SVNKit JDT BST SaffBE Peachtree
% LocalWords:  alternateAbstract parallelizing uniprocessor noninteracting Saff
% LocalWords:  subcomponents NOTEaboutsupersededby vertices profilers multi jsr
% LocalWords:  pseudoauthor Raimondas Lencevicius substitutability uptime IGJ
% LocalWords:  composability Palulu ArtziEKPP Shuvendu Lahiri NOabstract igj
% LocalWords:  NOTbasefilename Sunghun OMITmonth QuinonezTE ArtziQKE ArtziKE
% LocalWords:  repro smcc Xiao Boshernitsan OPTdownloads OPTsupersededby Amit
% LocalWords:  ArtziKDTDPE Paradkar OPTtype OPTdownloadsnonlocal IBMTJWatson
% LocalWords:  IBMHawthorne pldi Flowcheck refimmutability Eclipsec nonnull XSS
% LocalWords:  classfile webapps NOdownloads TODOsupersededby toolset DigME Fai
% LocalWords:  Marrero parallelize AliZPE PapiAE KiezunGJE Karthick Jayaraman
% LocalWords:  SQLI Ardilla google multicores reengineer Concurrencer refactors
% LocalWords:  KiezunGGHE Vijay Hooimeijer HAMPI HAMPI's jase TODOdownloads ayy
% LocalWords:  TipFKEBDS Ittai Balaban Sutter refactiorings Saman Bachrach Weng
% LocalWords:  PerkinsKLABCPSSSWZEP Carbin Stelios Sidiroglou SOSP OPTabstract
% LocalWords:  OPTbasefilename ClearView elyv concolic Ernst89a csetags
% LocalWords:  mitacmug1989 mernst plse Ernst89 ErnstF89 aaai1989 Ernst89c
%  LocalWords:  coauthorship AIV7 AIM1369 aim1369 Ernst92c Ernst92e POPL94
%  LocalWords:  tradeoffs Ernst92d Ernst93a Ernst92g ErnstY93 ErnstY94 R11
%  LocalWords:  Ernst93b Ernst95 WeiseCES94 POPL94addr ASU86 CLZ86 FOW87
%  LocalWords:  AWZ88 RWZ88 BR91 KRS92 DS93 MR79 Dha91 popl94 tr9413 tr638
%  LocalWords:  Ernst94 SlicingTR9414 tr9414 tr9523 IR95 ir95 tr9524 TR823
%  LocalWords:  Boolos92 Boolos95 YuvalE1997 ijcai97 IJCAI97date ErnstKC98
%  LocalWords:  IJCAI97addr ECOOP98 ECOOP98addr ECOOP98date ecoop98 ICSE99
%  LocalWords:  ErnstCGN98 ErnstCGN2001 ErnstCGN99 ICSE99addr ICSE99date
%  LocalWords:  icse99 Ernst99 Ernst2000 ErnstCGN99relevance ErnstCGN2000
%  LocalWords:  undergradCoauthor ErnstGKN99pointers ErnstGKN99 tr991102
%  LocalWords:  notkin ErnstBN99TR tr970406 ErnstBN2002 ICSE2000 icse2000
%  LocalWords:  icse2000addr icse2000date ErnstCGN2001TSEnote tse2001 S477
%  LocalWords:  Ernst01 NimmerE01 tr823
%  LocalWords:  rv2001 KataokaEGN01 ICSM2001 ICSM2001addr ICSM2001date Xie
%  LocalWords:  icsm2001 StreckenbachS2004 NimmerE02 ISSTA2002 issta2002
%  LocalWords:  ISSTA2002addr ISSTA2002date FSE2002 FSE2002addr fse2002
%  LocalWords:  FSE2002date DodooDLE02 DodooLE2003 Dodoo02 NeWinE02 TR841
%  LocalWords:  NeWinEGKL03 tr841 WilmerE02 dm2002 tse2002 WilmerE03 tr889
%  LocalWords:  ALICE03 VMCAI2003 VMCAI2003addr VMCAI2003date NeWinEGKL04
%  LocalWords:  vmcai2003 HarderME03 ICSE2003 ICSE2003addr ICSE2003date
%  LocalWords:  icse2003 Harder02 DonovanE03 DonovanKTE2004 practise R0309
%  LocalWords:  OMITcsetagsBECAUSESUPERSEDED BurdyEtAl03 trr0309 Ernst2003
%  LocalWords:  WODA2003 WODA2003addr WODA2003date woda2003 MeghaniE2003
%  LocalWords:  FMICS03 FMICS03addr FMICS03date BurdyCCEKLLP2005 fmics2003
%  LocalWords:  McCamantE2003 FSE2003 FSE2003addr FSE2003date fse2003
%  LocalWords:  tr914 SaffE2003 ISSRE2003 ISSRE2003addr ISSRE2003date
%  LocalWords:  issre2003 LinE2003 ISSRE2003supplementary LinE2004 tr941
%  LocalWords:  McCamant2004 McCamantE2004 SaffE2004 ETX2004 ETX2004addr
%  LocalWords:  ETX2004date etx2004 BrunE2004 ICSE2004 ICSE2004addr leelin
%  LocalWords:  ICSE2004date icse2004 PASTE2004 PASTE2004addr paste2004
%  LocalWords:  PASTE2004date ECOOP2004 ECOOP2004addr ECOOP2004date tr968
%  LocalWords:  ecoop2004 sttt2004 ISSTA2004 ISSTA2004addr ISSTA2004date
%  LocalWords:  issta2004 PachecoE2004 PachecoE2005 BirkaE2004 OOPSLA2004
%  LocalWords:  OOPSLA2004addr OOPSLA2004date oopsla2004 ConstJava FSE2004
%  LocalWords:  DonovanKE2004 SAVCBS2004 SAVCBS2004addr SAVCBS2004date
%  LocalWords:  savcbs2004 PerkinsE2004 FSE2004addr FSE2004date fse2004
%  LocalWords:  ErnstC2005 ICSE2005 ICSE2005addr ICSE2005date icse2005
%  LocalWords:  Ernst2006 SaffE2005 SaffAPE2005 tr991 sttt2005 BurdyEtAl05
%  LocalWords:  ECOOP2005 ECOOP2005addr ECOOP2005date ecoop2005 lockcaps
%  LocalWords:  WilliamsTE2005 Ernst2005 VSTTE2005 VSTTE2005addr vstte2005
%  LocalWords:  VSTTE2005date TschantzE2005 OOPSLA2005 OOPSLA2005addr
%  LocalWords:  OOPSLA2005date oopsla2005 Tschantz2006 ArtziE2005 ASE2005
%  LocalWords:  PASTE2005 PASTE2005addr PASTE2005date paste2005 ase2005
%  LocalWords:  ASE2005addr ASE2005date ErnstP2005 ASE2005base ErnstLP2006
%  LocalWords:  ASE2005tutdate WSMATE2006 WSMATE2006addr WSMATE2006date
%  LocalWords:  wsmate2006 Nokia DemskyEGMPR2006 Demsky ISSTA2006 Freeciv
%  LocalWords:  ISSTA2006addr ISSTA2006date issta2006 RinardE2006 CSAIL
%  LocalWords:  GuoPME2006 bytecodes dAmorimPMXE2006 Darko ASE2006 ase2006
%  LocalWords:  ASE2006addr ASE2006date Symclat