[abc] abc static analysis bug (fwd)

Ondrej,

Can you take a look at this?

Thanks, Laurie

+-----------------------------------------------------------------
| Laurie Hendren --- laurie.hendren@mcgill.ca
| Associate Dean (Academic), Faculty of Science,
| Dawson Hall, McGill University, 853 Sherbrooke St W,
| Montreal QC H3A 2T6 Canada, 514-398-7179, fax 514-398-1774
+----------------------------------------------------------------
| For contact and home page info as Professor, Computer Science:
| http://www.sable.mcgill.ca/~hendren --- hendren@cs.mcgill.ca
| Research: http://www.sable.mcgill.ca http://aspectbench.org
+----------------------------------------------------------------

---------- Forwarded message ----------
Date: Mon, 30 Jan 2006 16:47:53 +0100
From: Sebastian Kanthak <skanthak@gmail.com>
Reply-To: sebastian.kanthak@muehlheim.de
To: hendren@sable.mcgill.ca
Cc: Mira Mezini <mezini@informatik.tu-darmstadt.de>,
     Michael Haupt <haupt@informatik.tu-darmstadt.de>
Subject: abc static analysis bug

Dear Mrs. Hendren,

we recently submitted a paper on cflow implementations to PLDI, which
was rejected. We have, however, received a very helpful review
detailing the cflow optimisations as applied by abc.

We are currently trying to incorporate some of the suggestions and are
performing a more detailed analysis of our benchmarks. It seems I have
hit a bug in abc's interprocedural cflow optimizations with our
benchmark (attached to this e-mail).

When compiling the benchmark with "-O3 -main-class TestAbc",
unconditional advice execution is woven into Foo.foo() (although it
can be reached outside the control flow) and Foo.m() does not contain
any logic for updating the state of the control flow (although it must
not be omitted, here). You can verify that something is wrong by
running the benchmark twice; the first time compiled with -O1, the
second time compiled with -O3. To run the benchmark, please use the
following parameters and notice the "count=<n>" parameter in the
output.

java TestAbc 1 10 5 10 1

When compiled with -O1, you'll get the correct value of "count=40",
but with -O3 a value of "count=120" will be printed.

I think the bug is caused by the way we spawn several threads in
CFlow.run. Apparently, your call graph analysis does not correctly
analyze which method gets executed due to Thread.start() (which is a
very hard problem, in general), but I'm sure you can debug this issue
better than I could.

I hope this information is helpful to you.

Sebastian Kanthak

--
Research Assistant
Software Technology Group
Darmstadt University of Technology, Germany