[abc] Tracematch / Program Monitoring paper

Hi all,

The deadline for OOPSLA submissions is 18th March. Following a
meeting with the Oxford abc guys earlier this week, I've listed
some of the things that I think need doing to the paper. They're
shown below, grouped by the contributions we claim in the
introduction. Any corrections/changes/additions will be greatfully
received!

Cheers,
Julian

 
 -------------------------------------------------------------
CONTRIBUTION: Program monitoring roadmap (of existing systems)
-------------------------------------------------------------

TASK: Create a table comparing program monitoring systems based
      on the one Oege did for the OOPSLA presentation.
 
 
 The introduction says that we will compare programing monitoring
systems in terms of: the underlying formalism, whether remedial
action (advice) is possible, and expressiveness.
 
TASK: Edit the system descriptions in the current draft so that
      in each case the formalism used is explicitly mentioned
 
 TASK: Clarify what systems allow remedial action (advice)
 
      It may be necessary to state that currently PQL does
      not allow multiple queries, and hence there can be
      only one piece of advice at a time
      (this will affect what benchmarks we can run on PQL)
 
 TASK: Include some discussion of expressiveness by explicitly
      mentioning when examples cannot be expressed in a
      system, and _why_.
 
 
 -------------------------------------------------------------
CONTRIBUTION: Benchmarked performance challenges
-------------------------------------------------------------

TASK: Polish the description of the challenges to
      implementing program monitoring efficiently
 
At a meeting earlier this week, the consensus was that we
should quickly review which benchmarks we would like to
include, and then have a bug-blitz until they all compile
correctly under abc.
 
 
TASK: Finalise choice of benchmarks.
TASK: Make them compile under abc
TASK: Automate benchmarking process
TASK: Collect numbers
 
 
-------------------------------------------------------------
CONTRIBUTION: Tracematch optimisations
-------------------------------------------------------------
 
 TASK: Polish description of the Tracematch implementation
 
 Oege suggested that we should investigate the overheads of the tracematch
filtering semantics. This is not as simple as using the abc-switch to turn
off negative bindings --- we need negation for the cases when you must be
able to forbid an event from occuring in-between other matching events.
 
 TASK: Extend the TM implementation with negation (does this mean we need
      intersection as well? !(A|B) = !A & !B )
 
TASK: Measure the overheads of filtering semantics
 
 TASK: Write about whether filtering is worth it.
 
 
 Currently there is some indecision as to the type of static analysis that
would be appropriate for optimising tracematches. As a start:
 
 TASK: Consult the literature, especially papers by those who claim to
      be able to declare a program safe with respect its use of iterators
      over mutable collections.
 
 
 -------------------------------------------------------------
CONTRIBUTION: Using TM optimisations on other systems
-------------------------------------------------------------
 
 Currently, this is the section that requires most work if we
are to claim it as a contribution.
 
 One approach:
 
 TASK: List a type of automaton for each formalism used for
      program monitoring. If possible, find out what is actually
      used in the implementation.
 
 TASK: How can the per-event work be minimalised for each type of
      automaton. Does minimising the automaton help? Determinising?
 
 TASK: What schemes for dealing with weak-references are possible
      with each automaton.
Received on Fri Jan 20 12:25:47 2006