RE: [abc] oopsla outline

Hi, Oege.

Thanks for the outline. This looks like a really good paper to me!

I would still like to add some information about the spec patterns
survey by Dwyer et al. if you don't mind. It is really very interesting,
especially w.r.t. future work (i.e. static optimization) because it
turns out that by optimizing only a few very common patterns, you can
already optimize 90% of all the use cases they encountered. So this
seems quite encouraging.

About benchmakrs:

> WOULD BE NICE TO ALSO HAVE ALPHA, or HAWK.

ALPHA:
I have now a version of Alpha which compiles and also kind of runs. I am
just not 100% sure how to correctly run the examples they provide. I
will try to contact Christoph Bockisch about that.

HAWK:
I also asked Klaus Havelund again about HAWK... Still no reply, though.

>
> WOULD BE GOOD TO TRY NULLTRACKER AND HASHCODE ON SOME OTHER
> EXAMPLES SUCH AS WEKA ...

What's weka?

APROVE:
Do we have this new indexing scheme working so that I can try and see if
Aprove now does any better?

JIGSAW:
Tonight I tracked down a bug in the native AspectJ LOR aspect. The
problem was that this aspect would not pick up all the LORs while the
tracematch would (under certain circumstances). Stangely after a long
time of debugging it turned out that the ReferenceMap implementation of
Jakarta Commons Collections was the problem! I would never have thought
that this class has a bug but it quite seems so: Reproducably, entries
were deleted too early. I then replaced the map by the WeakHashMap of
the JDK (we need no identity map here, since I only have Threads as keys
and those do not implement "equals" anyway) and it all worked fine!

Anyway - I am not entirely sure how to interpret the benchmark output
(help on that is appreciated) but assuming that the rightmost column
shows timestamps then the TM version seems to be only about 70% slower
in my runs. This is quite astonishing, especially given that the regular
expression is so large. So I guess I will have to verify this though
further runs... I am confident that we get reliable numbers within the
next day or two. But anyway it was quite difficult to get the native AJ
aspect right. So at least in terms of usability and maintainability, TMs
win here quite clearly.
Received on Thu Mar 02 02:56:38 2006