[abc] oopsla paper

Dear all,

I've just finished going through the oopsla paper. I have rather few
comments - it reads extremely well, and is impressively water-tight
(as one would expect given that much of the work is about avoiding
leaks...) - sections 1-3 do a very good job of convincing the reader
of the problems.

Minor comments:

p.6 Figure 5: as I can't tell the difference between the line styles
in the graph, it would be helpful to have labels next to each line (or
the items in the key appearing in the same vertical order as the
lines). Otherwise the graph can't be understood without reading all
the text as well

p.7 paragraph following "Challenge 2": "The poor performance of
TMNoIndex ..." - what is the slowdown between TMNoIndex and TM? Even
with log-scale, it looks smallish on the graph (certainly less than
the difference between TMNoFilter and TM)...

p.8 right column, "Observer" paragraph. "In that version..." that
sentence is ambiguous to me. Does it mean "In JHotDraw, updating of
figure displays is done via standard Java listeners; in AJHotDraw we
replaced..." ?

p. 10 table 3: nice numbers! :-)

p.10 left column (section 5.1): "one way of making a performance
comparison is to look at PQL (...) versus that of tracematches (...)"
-> to look at the _performance_ of PQL versus that of....

p. 11 column 2 (end of section 5). Is it possible to use the AspectJ
version without contains() to compare? if not, mention it

===> Section 6

=> 6.1

p.12, left column. Mention that the alphabet of the automaton is the
set of symbols, and define skip before introducing the automaton of
Figure 7

p.12, right column. "For this reason each tracematch NFA is converted
to a minimal DFA during compilation..." This is a tricky point because
there are several automata at different stages of the constructions,
and some of them are definitely NFAs (because of the skip loop
requirement). Am I right in thinking that the _pattern_ automaton is
converted to a minimal DFA, not the actual automaton matched at
runtime? Also the minimal DFA may be larger than a minimal NFA but (I
think) is easier to compute.

Reading the paragraph again I see that all the info is there, but it
wasn't clear on my first read

=> 6.2 and 6.3

Sections 6.2 and 6.3 seem a little bit abstract as they stand. The
second paragraph could briefly remind the reader (from 6.1) that each
state is labelled with a formula built from equalities and
inequalities, and /\ and \/. These can be represented in DNF, so we
need a good representation of Disjuncts, ie conjunctions of equalities
and inequalities. A constraint is just a disjunction (set) of these.
Then as before.

I'm not quite sure how to make 6.3 more concrete though. Is it
possible to give a partial signature of Disjunct (specialised) and
Constraint in a figure? Or just the operations on them, informally?

=> 6.4

2nd and 3rd paragraph: so that the reader doesn't get scared when we
start talking about analyses, change "the brunt of the analyses happen
on the automaton..." to saying that it be should stressed again that
no expensive whole-program analysis is required, and that this is in
fact a local analysis of the tracematch automaton itself.

After the "StrongRefs / WeakRefs / CollectableWeakRefs" list: I think
the paragraph detailing when we give warnings should be moved to
_after_ describing when space leaks can occur (next 3 paras). This
seems more logical:
  1. How do we avoid leaks?
  2. What cases are left? Give a warning for these.

=> 6.5

I do agree with the comment that a diagram would be nice, if there is
time - but it is understandable without it.

Typo. p.15 column 2 "States are, in general [...] , if possible.." Two periods

=> Future work

p. 17, column 2, end of section 7.3 - comments on SLAM are a bit
unclear. Also, SLAM doesn't really do a static analysis (it might run
forever). Ignoring variable bindings, I can see how a declare error
tracematch is essentially what SLAM does though

=> Conclusion

Typo p. 18 column 2: featuers

That's all from me, nice paper!

Cheers,
Damien

--
Damien Sereni
Research Officer
Oxford Centre for Metacomputation
http://metacomp.comlab.ox.ac.uk
Office: (+44) (1865 2) 83512
dsereni@gmail.com / dsereni@comlab.ox.ac.uk
Oxford University Computing Laboratory
Wolfson Building, Parks Road
Oxford OX1 3QD
UK