JRockit powered AOP prototype available

(imported from http://blogs.codehaus.org/people/avasseur, read comments there)

It's there !

I am very pleased to announce the prototype version of JRockit that includes our AOP API is available. It will drive you far far away from current bytecode instrumentation techniques to a world of plain Java API, complete runtime control for hot deployment and undeployment, agnostic from the programming model you like for your aspects.

If you are involved in the AOP field, bytecode instrumentation field, APM field, and did not heard from us recently, please drop me an email and I 'll consider your participation in evaluating this technology to help us drive it to reality.

You can read the official announcement and some background information in our BEA dev2dev dedicated forum.

Synchronized block join points (v2)

(imported from http://blogs.codehaus.org/people/avasseur, read comments there)

Back in July Jonas suggested some semantics for a synchronized block join point. The discussion was interesting but I am wondering if we actually came up with the right question.

What if we simply think in terms of "is this type listening to locking events ?" instead of trying to come up with a pointcut expression that defines the semantics of a synchronized block - as done in Jonas discusion?

Lets draft some code:


Consider the program:

class Bar {
synchronized void foo() {
..
}

static synchronized void statfoo() {
..
}

void stuff() {
..
synchronized(bar) {
..
}
}
}


So the deal is to listen to lock events - mainly:

• waiting the lock


• just acquired the lock


• just released the lock (or perhaps about to release it - but this does not matter much for this discussion)

I argue that instead of defining semantics, the issue should be narrowed to a type pattern ie something as simple as Bar (or more fancy variations based on type hierarchy or annotation - you bet it).

Given that we can define this interface:

interface Lockable {
void waiting();
void acquired();
void released();
}


As a user you can then implement this interface on your own types, use some sort of AOP or proxy to have it introduced where you want, etc.

So what should happen to make that work?

First based on the type pattern, we simply introduce Lockable to Bar. This can be done manually, by the mean of AOP if f.e. I was writing @Distributed class Bar { .. } and so on - depends on the use case.

Second the interface must then be implemented by Bar.
The user can provide one if implemented manually, or the system (AOP f.e.) can provide an empty one ie something like (depends on the AOP system but you get the idea)

@Introduce("Bar")
class LockableNOOP implements Lockable {
void waiting() {}
void acquired() {}
void released() {}
}


Last we need to transform the program so that the synchronized block or the Bar' synchronized method are triggering event to that.
This is not that hard since we just need to look at the type hierarchy for non static synchronized method and given that an instance synchronized method can be rewritten (by the system) as a synchronized(this) block we end up to something like that:

Replace all synchronized blocks like that:

Given

synchronized(stuff) {
..
}

to

if (stuff instanceof Lockable) {
Lockable lockable = (Lockable)stuff;
lockable.waiting();
synchronized(stuff) {
lockable.acquired();
..// unchanged body
}
lockable.released();
} else {
synchronized(stuff) {
..// unchanged body
}
}

Fairly easy.

So far, nothing will happen, as we have a LockableNOOP implementation, unless the user (you) explicitly provided some implementation.

Last part: configure the system so that it advises Lockable' methods, so that you can add your behavior there (f.e. distribute lock, or trace them for some application performance system). There, usual AOP stuff can be used.

You can now access the enclosing static join point information if you need - which gives you if you really need it, the rich semantics Jonas was looking for:

call(Lockable.waiting()) && withincode(....) && target(t) && cflow(...) .....
// t is the locked object


There are two interesting things to solve now:

• What if I want to kick out the synchronized() block ?(f.e. for distributed lock). I think a small variation of Lockable can solve that - f.e. boolean shouldUseJavaLocks(), and a tiny change for the transformed program.


• What about the static synchronized statfoo() {..} in Bar? For that one, the transformation would have to be a bit more compex so that we f.e. lock on an introduced static field. That said, the Lockable interface is not handy anymore. Any suggestion for that one? Should we define three methods like static void lockable_waiting() that ones would implement or introduce to adress this use case?

On a more high level perspective, this send us back to a recurrent set of problems in the AOP / bytecode transformation space:

• to achieve API transparency, we have a very intrusive transformation engine (though the one described here can be quite fast)


• by changing the bytecode we break the visibility another system may require to work properly (as f.e. we add if blocks, change synchronized method into synchronized blocks etc).

There is thus a set of open questions:

• So should that belongs to the JVM directly, and in which form?
  (as f.e. JVMTI already provides monitor entry / exit events, that should be fairly easy).


• Should those 3 Lockable' methods (or 6 if we include the static versions) belong to java.lang.Object direclty?


• Would an hybrid system that changes the synchronize blocks using bytecode transformation but then relies on JVM level support for AOP such as we do in JRockit be enough to listen for lock events?


• Is the cost of the introduced instanceof acceptable?

Happy thinking!