• time to acquire the lock : need an advice just before the lock is acquired and one (possibly the same is there are sort of a proceed concept) just after it is acquired

• time spend with the lock (ownership) : need an advice just before (or after) the lock is released

• lock implementation : bypass the JMM lock and use something else - possibly with conditional logic such as ” if (t is distributed) { getADistributedLock(); proceedWithoutJMMLock(); releaseDistributedLockFinally(); } else { proceedWithJMMLock(); (or possibly proceed() and let the user add is own enclosing JMM synchronized(t) {proceed();} }

How each of those would be implemented by the proposed semantics ?

1) Though the monitor enter/exit don’t have to be paired in the bytecode you will find that JVMs will puke on them not being paired with the same method. Also, the last time I checked many JVMs will puke if they are interleaved, eg:

monitor1.enter() monitor2.enter() monitor1.exit(); monitor2.exit();

Even though that construction would be very useful for navigating trees of information.

2) The bytecode for synchronized methods vs. a method enclosed enitrely within a synchronized block are actually different and will go through different code paths in the JVM.

My suggestion is the you have 2 new pointcuts, monitorEnter and monitorExit that you can apply before/after/around advice to. Basically treat them as method calls whose target is the object that is being used as a monitor.

2) The bytecode for synchronized methods vs. a method enclosed enitrely within a synchronized block are actually different and will go through different code paths in the JVM.

Right, this is the reason why call(synchronized .(..)) and execution(synchronized .(..)) are semantically different in regards to the locking (since the locking is not seen as part of the method body).

But it is conceptually equal to locking on ‘this’ (and was stated there only to drive the discussion).

My suggestion is the you have 2 new pointcuts, monitorEnter and monitorExit that you can apply before/after/around advice to. Basically treat them as method calls whose target is the object that is being used as a monitor.

I wanted to stay neutral, at least in the beginning of this discussion, but this (the 1:st solution in the post) is actually the one I prefer (probably the only one that makes sense). By the way, it is the only solution that addresses all use cases that Alex defined in his comment.

Thanks all for your comments.

@SomeAnnotation(…) {…}

@SomeAnnotation(…) synchronized(…) {…}

for(…) @SomeAnnotation(…) {…}

if() @SomeAnnotation(…) {…} else @AnotherAnnotation(…) {…}

try @SomeAnnotation(…) { } catch() @AnotherAnnotation(…) { }

So, this can actually go into a custom attribute that would have start and end offset in the method bytecode (similar to try/catch) and then value of the annotation for this block. Perhaps such atribute can even make into Dolphin…

I really like your proposal, but it should not end up in the AJ compiler but in the real spec.

Unfortunately you will run into problems with interleavind monitorenter/exit statements (see above), which cannot be disambiduated statically. So you would need runtime instrumentation for this! There is no general way around.

W.r.t. the “block” pointcut, I think that a) it would be a huge overkill (why not extract a method if I want a semantic block?) and also some blocks are agaibn not statically defined by the bytecode, so for instance exception handlers, which have no defined end…

Anyway, I’ve started a thread in Mustand discussion forum. Please leave a comment or two out there. http://forums.java.net/jive/thread.jspa?threadID=988&tstart=0

By the way, Eric, with this functionality on a Java code level you should not have issues with an interleaved blocks because compiler will generate a proper ranges.

I disagree about the overkill. Because all annotated blocks are visible on a method level it is actually more lightweigh option then extracting methods. It would also allow to add e.g. onException adviced only for annotated exeption blocks, which is not that easy to do with currently available pointcut definitions (especially if you have two nested exception handles on the same exception type).

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).

Jonas Boner blogged about expressing “synchronized” constructs within method code in AOP semantics.

Well, it shouldn’t be difficult to build a dataflow tree for all synchronized blocks in any given method, and then address each block using some X