Eric Bodden

20°C

I am happy to announce that my latest research paper has been accepted for publication at AOSD 2009. The paper is titled Dependent advice: A general approach to optimizing history-based aspects (paper here), and that’s really what it is about. If you know my past work, then you also know that my work is concerned with evaluating runtime monitors based on tracematches at compile time. The purpose of Dependent Advice (an extension to ordinary AspectJ advice) is to generalize this idea. With dependent advice, one can apply the same powerful whole-program optimizations to normal aspects that previously one could only apply to tracematches. Sounds exciting? So how does it work?

History-based aspects

First of all, our approach assumes that you have a history-based aspect, an aspect that contains some pieces of advice that are interdependent. In other words, one piece of advice only needs to execute if another one will execute (or has executed) on the same object. Many monitoring aspects have this property, for instance the aspect on the right. This aspect monitors the events of disconnecting and reconnecting a connection c, as well as writing data to c. Note that almost all the aspect code is concerned with bookkeeping internal state. This can induce a large runtime overhead. The error message at line 17 implements the only functionality that is visible outside the aspect. Note that the aspect prints the error only if both the advice disconn and write execute on the same connection c. In addition, the advice reconn only has to execute on connections that are both disconnected and written to at some point in time.

Now the important point is that compilers could use this important information to apply powerful optimizations: For example, one does not have to monitor disconn(c) if the connection c is never written to. Unfortunately a programmer cannot express this crucial domain knowledge in plain AspectJ syntax, and it would be very hard for an AspectJ compiler to re-construct this knowledge solely based on the aspect code. This impedes crucial optimizations.

Dependent advice

Dependent advice solve this problem. A dependent advice  contains dependency annotations to encode crucial domain knowledge: a dependent advice needs to execute only when its dependencies are fulfilled. For the “connection” example from above, a programmer could add the annotation dependency{ strong disconn, write; weak reconn; }

This annotation conveys the information that the execution of the advice disconn and write both depend on one another, and in addition the execution of reconn depends on both disconn and write to execute at some point in time.

For the AOSD paper, we have taken our previous analyses for tracematches, and converted them so that they work on ordinary aspects, given that these aspects have been annotated with dependency information like the above. But you may ask: “Would a programmer really be able to come up with these annotations?” We asked this question ourselves, and we thought “maybe”. However, if not, then the programmer can simply use tracematches, or JavaMOP, or any other finite-state based monitoring tool that generates AspectJ aspects, and have this tool generate these annotations automatically.

Generating dependent advice from monitor specifications

As a proof of concept, Feng Chen implemented an appropriate code generation scheme in JavaMOP. Given a monitor specification in the form of an extended regular expression or a past-time or future-time linear-temporal-logic formula, MOP generates an aspect that contains dependent advice. When the programmer then weaves this aspect into a program using the AspectBench Compiler, the compiler will automatically conduct a whole-program optimization and will spit out a program that contains an optimized runtime monitor. You can have look at some of these aspects and the monitor specifications for which these aspects were generated here.

In addition, as the figure shows, I re-programmed the tracematch-based analyses completely. In principle we do no specialized analysis for tracematches at all any more. We just generate dependent advice (internally, in the abc compiler, not in source) and then we apply the analyses from there.

Interested in the full details? Download the paper here.

Availability

Dependent advice have been available already since version 1.3.0 of abc (I just did not tell you about it ). To enable the extension, simply type…

java –cp abc-complete.jar abc.main.Main –ext abc.da

Note however, that this version does note yet take advantage of the new JastAdd-based frontend for abc, and therefore does not support Java 5 syntax. However, I have a new, JastAdd-based version of the extension checked into abc (called abc.ja.da), and you can get it via SVN. It just has not been released yet. For SVN access, do:

svn co http://abc.comlab.ox.ac.uk/products/trunk/abc-with-tests

Related posts and pages:

1. Feng Chen has passed away I just received the very sad and disturbing news that...