Re: [abc] ecoop paper

Hi Damien,

I think you make very good points and you should feel free to edit
the paper.

Laurie

+-------------------------------------------------------------+
| Laurie Hendren, Professor, School of Computer Science |
| McGill University |
| 318 McConnell Engineering Building tel: (514) 398-7391 |
| 3480 University Street fax: (514) 398-3883 |
| Montreal, Quebec H3A 2A7 hendren@cs.mcgill.ca |
| CANADA http://www.sable.mcgill.ca/~hendren |
+-------------------------------------------------------------+

On Sat, 18 Dec 2004, Damien Sereni wrote:

> Hi all,
>
> I've just finished a go through the paper and checked in some tweaks
> to the intro & section 2, plus some typos fixes. I'm going to start
> working on related work / conclusion now. Some more or less random
> comments on the main sections:
>
> 4.1 Polyglot-based frontend. The description of the frontend is too
> vague for me to understand it properly. eg paras 2-3 the overall
> implementation of semantics checks is described but at this stage we
> have no idea what the aspectj-specific checks are.
>
> Some suggestions for 4.1, what do people think about this?
> - leave lexing / parsing as it is
> - very briefly describe all the semantics checks that need to be
> done [ie mention that declare parents introduces constraints on
> hierarchy, and ITD checks...]
> - Give fig. 4 at that point to show overall structure of frontend
> - The discussion of dependencies between passes needs far too much
> background to leave in here; suggest either leave out altogether or
> replace with one example
> - "the semantic checking of AspectJ source files depends on the
> static weaving"... Does it really? (I haven't got my list of aspectj
> passes with me!) - in that case it's in the backend anyway... If
> semantic checks do occur in the backend this should be mentioned here.
> - Finally comment on separation from Polyglot (ie current third para).
>
> 4.4 make more of a big deal of reweaving; this is the major
> contribution of the architecture of abc (I've emphasized it again in
> the intro). Make it clear that reweaving allows analyses of AO
> constructs without the pain of having to eg construct an
> aspect-specific call graph.
>
> 5.1 Name matching: again it's difficult to get the point and we lack
> the space to extend it. Suggest collapsing last 2 paras into one,
> omitting discussion of EvaluatePatternsAThirdTime...
>
> 5.3 ITDs: §2 Visibility:
> - rephrase last sentence, not 100% clear to me
> §5 AspectInfo and Code Generation: "second, the weaver will
> correctly use the aspect as the lexical scope..." - this is a rather
> tricky point, esp if people are not familiar with AspectJ. Expand or
> remove?
>
> 5.4 Advice
> 5.4.1 Matching
> §1 Regularised pointcut language: it's a bit hard to get an idea
> of the problem from the first two paras. Suggest giving execution(int
> foo()) as example first, and then splitting the things to be matched
> against (class / method / statement) afterwards. Could save a couple
> of lines ... :)
> 5.4.2 Weaving
> The intro to weaving could be expanded a bit to make it clearer
> what the goal is before going into details [in particular preparing
> join point shadows...]
> §2 Inserting advice: is the discussion of where after throwing
> advice needs to be placed really relevant or just a minor detail? If
> minor, leave out [space reasons]
>
> 6 Comparison to ajc
> 6.1 The point that abc is better separated from its components is
> made clearly, no comments on this section
> 6.2 last para: "when one compares like with like (ajc+soot and
> abc)". Isn't ajc and abc -O0 also comparing like with like? Of course,
> in that case we are substantially slower... because of the cost of
> converting jimple to bytecode or just load times for soot? In any case
> I think this should be addressed as reviewers might wonder about this
> Fig. 9. How painful would it be to make the bytecodes / Jimple
> statements inserted in weaving boldface? This would make it easier to
> understand the figure without referring too much to the text.
> 6.4 Weaving strategy. There is a bit of overlap in the way this is
> introduced with 5.4.2 weaving (in particular when we mention
> inserting nops). Rename to "Using standard Soot optimisations" and put
> more emphasis on this, payoff being that we can do more things than
> ajc [rather than convenience in weaving, which is how it is phrased at
> the moment]
>
> Related work, conclusion: I'll look at those in a bit, the goal being
> to make the contributions more apparent in the conclusion, so it
> doesn't look like an experience report...
>
> General point:
> - We ought to have a ref to Hilsdale, Hugunin & Sunnyvale (AOSD
> 2004) as the only other paper that describes compilation of AspectJ
> (advice weaving anyway). Should be mentioned in sec 6
>
> Any comments on these points would be welcome! I'll work them in
> tomorrow if people are ok with them, but as they are nontrivial
> thought it would be better to check.
> It's worth keeping in mind that we are half a page over; should be
> easy enough to get rid of, we can certainly do a bit of reference
> packing etc but we don't want to add too much stuff now
>
> Cheers,
> Damien
>
> --
> Damien Sereni
> Oxford University Computing Laboratory
> Wolfson Building, Parks Road
> Oxford OX1 3QD
> UK
>
> dsereni@gmail.com / dsereni@comlab.ox.ac.uk
> http://web.comlab.ox.ac.uk/work/damien.sereni
>
>
Received on Sat Dec 18 18:40:07 2004