grubbel - Semantics for a Synchronized Block Join Point

Semantics for a Synchronized Block Join Point

[ jonas ] 12:07, Monday, 18 July 2005

As I mentioned in my previous blog entry, the

synchronized

block is currently not a supported join point in AspectJ 5 (or in any other AOP framework):

Currently you can for example pick out a call to a method that is declared as being synchronized and you can pick out calls to Thread:: notify()/notifyAll()/wait(). Meaning that being able to pick out synchronized blocks are the only missing piece left in order to completely control thread management and locking in Java. The actual bytecode modifications needed to make this work would be fairly simple, but capturing the correct semantics in a good language design would probably be a lot trickier.

Well, I'm not a language designer, but I think the problem is interesting so I will spend some time discussing it anyway.

In bytecode, a synchronized block is represented as a MONITOR ENTRY and a MONITOR EXIT bytecode instruction pair (however these are not required to be paired). The first natural approach would to let these two bytecode instructions be join points and treat them similar to field access and modification (PUTFIELD and GETFIELD bytecode instructions), meaning simply pick out (and intercept) this single bytecode instruction.

Just to clarify what I mean, here is an example of how the syntax for the above given semantics could look in the AspectJ pointcut expression language:

lock(Type t) && withincode(* Foo.bar(..)) && args(t)

unlock(Type t) && withincode(* Foo.bar(..)) && args(t)

Let us take a look at a synchronized block and how it would be affected:

synchronized(obj) {
     // body
}

In bytecode to this is equivalent to (pseudo code):

MONITOR ENTRY // lock on obj
    // body
MONITOR EXIT

If we now add around advices to these join points then we could for example get (pseude code):

try {
     // a call to the around advice, which calls the lock manager
     aroundAdvice1(obj) --> myLockManager.acquire(obj); 
 
     // body
 
} finally {
     aroundAdvice2(obj) --> myLockManager.release(obj);
}

This approach would give you the possibility to completely control how locking is done in Java (including the possibility of enhancing or completely screw up the Java Memory Model (JMM)). On the other hand it does not allow you to pick out the actual code block that is synchronized (is this something that we want?) . Therefore this approach is perhaps not intuitive, since in Java source code, what we see is not lock acquisition and release but a code block that is guaranteed to be synchronized. So now let's try to approach this problem from the perspective of source code.

Since AspectJ (and AspectWerkz) already has limited support for the synchronized keyword by allowing calls to methods declared as being synchronized to be matched, let us take a look at the semantics for this join point.

Here's a simple method that is defined as being synchronized:

public synchronized void doStuff() { 
     // body
}

What this actually means is:

public void doStuff() { 
     synchronized(this) {
          // body
      }
}

The options we have of picking up this synchronized code block (wrapped up in the doStuff() method) is by using a

execution(synchronized void *.doStuff())

call(synchronized void *.doStuff())

pointcut.

Using the execution pointcut, the above method body would be transformed to (pseudo code):

synchronized(this) {
     // the advice has option of invoking the original body
     myAroundAdvice(this) 
}

I.e. only synchronized body is matched and intercepted.

If we are using the call pointcut, the same code snippet would be transformed to (pseudo code):

...
// the advice has the option of invoking the original synchronized block
myAroundAdvice(this) 
...

I.e. the whole synchronized block, including the locking is matched (and intercepted). (This is conceptionally true, in regards to the locking, which is easy to see if you think of the doStuff() method as being inlined.)

I will not go into much detail about how these semantic differences should be expressed in the pointcut language here (this post is too long already). But for example, the last discussion would require the possibility of making a distinction between picking out a code block inclusively and exclusively (i.e. picking out the whole code block, or just the body of the code block), which could be expressed something like this:

// pick out synchronized block including the locking
block-inclusive(synchronized(Type t)) && withincode(* Foo.bar(..)) && args(t)

// pick out only the synchronized block's body, not the locking
block-exclusive(synchronized(Type t)) && withincode(* Foo.bar(..)) && args(t)

(These "block" pointcut descriptors can of course be used in any kind of block, loops, conditional statements etc., if/whenever they are supported in AspectJ.)

To sum up, the questions are: Do we want the power of intercepting the whole locking mechanism (but not the synchronized body), or is it better to follow the semantics we have for a synchronized method? Which approach addresses the use cases we want? Is the most intuitive? Is more orthogonal?

Thoughts? Comments? Ideas?

TrackBack

Hello,
As pointed out by Laurie Hendren and Eric, it can be very difficult and possibly impossible to have a solution for the general case at compile-time.

However, I think there might be a solution for a large number of cases.
This would consist of:
1/ building the exceptional basic-block graph for the method.

2/ Finding the monitorenter instruction, and the block immediatly after (it should always be the case, since it's the beginning of a trap)

3/ There should be (I guess) a couple of blocks (one "normal" and one handler for the finally/monitorexit) that "post-dominate between them" the monitorenter block (i.e. it is compulsory to go through one of them before returning from the method).

4/ The subgraph between the monitorenter instruction, and the "post-dominating" monitorexits would then represent the synchonized block.

(This would be a similar approach to the potential if-then-else join point I've suggested at the end of the paper on the join point for loops presented in FOAL 2005. I would not encourage an if-then-else join point, though.)

One remaining problem would be to make sure that the monitorenter and monitorexits match the same reference.

If you take this simple program:

public void run() {
System.out.println("A") ;
synchronized(this) {
System.out.println("B") ;
}
System.out.println("C") ;
}

Here is its jimple representation, based on the bytecode generated by Eclipse JDT (see Soot: )

public void run() {
Test r0, r2;
java.io.PrintStream $r1, $r4, $r6;
java.lang.Throwable $r5;

r0 := @this: Test;
$r1 = ;
virtualinvoke $r1.("A");
r2 = r0;
entermonitor r0;

label0:
$r4 = ;
virtualinvoke $r4.("B");
exitmonitor r2;
goto label2;

label1:
$r5 := @caughtexception;
exitmonitor r2;
throw $r5;

label2:
$r6 = ;
virtualinvoke $r6.("C");
return;

catch java.lang.Throwable from label0 to label1 with label1;
}

Here, the problem is that r0 and r2 represent in fact the same reference. Because synchronised blocks are always within the same method, it should not be too difficult to see which variables used my the monitorenter/monitorexit contain the same reference.

This would require further investigation, and perhaps a prototype implementation (in abc for example).

--Bruno Harbulot, August 2, 2005 02:57 PM