Congratulations to Jonas and team!

The final release of AspectWerkz 1.0 has been released. This release added some new facilities like new Ant tasks for strongly typed annotation compilation and weaving from the last Release Candidate.

As a reminder, AspectWerkz 1.0 supports the following:

• Aspects, advices and mixins are plain Java
    
  • Before, Around, After advices
  • Method and interface introduction (mixin)
  • Aspect (singleton, perClass, perInstance, perThread)
• Pointcuts are composable
    
  • Method and constructor call and execution
  • Field read and write access
  • Matching on types and signatures
  • Matching on Annotations (Java 1.3/1.4 strongly typed annotations)
  • within(..), hasfield(..), hasmethod(..) and withincode(..) designators
  • cflow supports
  • args(..) designators to gain strongly typed access to advised member parameters
• Aspects definitions allows deployment modules
    
  • Aspects defined as annotated classes
  • Aspects defined and refined in XML
  • Deployment module with META-INF/aop.xml
• Annotation driven AOP
    
  • Custom annotation compiler for Java 1.3/1.4 which behave like Java 5 annotations, available thru Ant task and command line
  • Strongly typed annotations support for Java 1.3/1.4
  • Matching on annotations on target classes and members
  • Definining Aspects, advices and pointcuts with annotations
• Integration facilities
    
  • Post compilation thru Ant task and command line
  • Class load time weaving thru JVMTI/JSR-163 for Java 5, plain Java hooks for Java 1.3, 1.4, JMAPI API for BEA JRockit, specific native module for Java 1.4

If you are not familiar with AspectWerkz, tutorials are available.

Download AspectWerkz 1.0
Read the release note.

AspectWerkz guys.
Really glad to see this news, it is C^OO^L. Keep your working;)

/Jack

Which penalization [ms] I have to pay for executing aspect?
How you can compare performance of AspectWerkz with other implementations (AspectJ)?
Are real (1.5) annotations supported in pointcut syntax?

I like idea of universal aspect which is than applied to my code through XML configuration. Good aspects should be shared between developers like black boxes. Only XML configuration will be different. However support for 1.5 annotations is necessary.

Which penalization [ms] I have to pay for executing aspect?How you can compare performance of AspectWerkz with other implementations (AspectJ)?

Very rough comparison is here:
http://kgionline.com/articles/aop_1/aop1.jsp#aspectwerkz

Konstantin,

It looks like direct Java call is about 60-70 times faster than the instrumented one at least for the simple "around" advice that you use in your test.

Is it a general rule for AOP implementations to be so much slower? As far as I know AspectWerkz uses byte code modification (not dynamic proxies), so it must be fast. Can anyone verify this?

By the way, I like AspectWerkz the most of all AOP implementations I have seen so far for its simplicity. I compared it to many other AOP frameworks, and by far it is the winner in simplicity and readability of instrumented code (at least as far as examples go).

Regards,
--Dmitriy.

Konstantin,It looks like direct Java call is about 60-70 times faster than the instrumented one at least for the simple "around" advice that you use in your test.Is it a general rule for AOP implementations to be so much slower? As far as I know AspectWerkz uses byte code modification (not dynamic proxies), so it must be fast. Can anyone verify this?By the way, I like AspectWerkz the most of all AOP implementations I have seen so far for its simplicity. I compared it to many other AOP frameworks, and by far it is the winner in simplicity and readability of instrumented code (at least as far as examples go).Regards,--Dmitriy.

I was actually surprised myself when I got those results. I did not expect that CGLib proxies would outperform bytecode manipulation….
That slowness does not bother me too much, it just indicates that at this moment AOP should be used carefully and mindless aspectization of everything might have very negative impact on application performance.

Konstantin,It looks like direct Java call is about 60-70 times faster than the instrumented one at least for the simple "around" advice that you use in your test.Is it a general rule for AOP implementations to be so much slower? As far as I know AspectWerkz uses byte code modification (not dynamic proxies), so it must be fast. Can anyone verify this?By the way, I like AspectWerkz the most of all AOP implementations I have seen so far for its simplicity. I compared it to many other AOP frameworks, and by far it is the winner in simplicity and readability of instrumented code (at least as far as examples go).Regards,--Dmitriy.

I was actually surprised myself when I got those results. I did not expect that CGLib proxies would outperform bytecode manipulation….That slowness does not bother me too much, it just indicates that at this moment AOP should be used carefully and mindless aspectization of everything might have very negative impact on application performance.

From my understanding, jbossaop (and maybe other aop framework) use javaassist to insert an interceptor before or after a method (it still use refection to inveoke the interceptor). The main different between proxy base AOP and jboss AOP is proxy base interceptor use refection for all the methods while jbossaop use refection for the method you want to intercept only. That is why you have cglib proxy base interceptor faster other aop framework.

Tuan Nguyen
www.exoplatform.org

Konstantin,It looks like direct Java call is about 60-70 times faster than the instrumented one at least for the simple "around" advice that you use in your test.Is it a general rule for AOP implementations to be so much slower? As far as I know AspectWerkz uses byte code modification (not dynamic proxies), so it must be fast. Can anyone verify this?By the way, I like AspectWerkz the most of all AOP implementations I have seen so far for its simplicity. I compared it to many other AOP frameworks, and by far it is the winner in simplicity and readability of instrumented code (at least as far as examples go).Regards,--Dmitriy.

I was actually surprised myself when I got those results. I did not expect that CGLib proxies would outperform bytecode manipulation….That slowness does not bother me too much, it just indicates that at this moment AOP should be used carefully and mindless aspectization of everything might have very negative impact on application performance.

From my understanding, jbossaop (and maybe other aop framework) use javaassist to insert an interceptor before or after a method (it still use refection to inveoke the interceptor). The main different between proxy base AOP and jboss AOP is proxy base interceptor use refection for all the methods while jbossaop use refection for the method you want to intercept only. That is why you have cglib proxy base interceptor faster other aop framework.Tuan Nguyen www.exoplatform.org

JBoss AOP does not use reflection anymore. There is only one object creation and that is a joinpoint object.

Bill

Which penalization [ms] I have to pay for executing aspect?How you can compare performance of AspectWerkz with other implementations (AspectJ)?

Very rough comparison is here: http://kgionline.com/articles/aop_1/aop1.jsp#aspectwerkz

This is very old. You should rebench as both JBoss AOP and AspectWerkz did a lot of performance work after your blog. I know because I talked to Jonas and Alex a lot at AOSD last year in March.

Bill

Which penalization [ms] I have to pay for executing aspect?How you can compare performance of AspectWerkz with other implementations (AspectJ)?

Very rough comparison is here: http://kgionline.com/articles/aop_1/aop1.jsp#aspectwerkz

I ported your bench to JBoss AOP. Here's the results:

     [java] Direct call::Test cycle took:30 ms with one call takes: 3.0E-5 ms. Counter:1000000
     [java] Using CGLib::Test cycle took:201 ms with one call takes: 2.01E-4 ms. Counter:1000000
     [java] Using JBoss AOP::Test cycle took:261 ms with one call takes: 2.61E-4 ms. Counter:1000000

I sent Konstantin the code, so its up to him if he wants to post it.

Bill

Which penalization [ms] I have to pay for executing aspect?How you can compare performance of AspectWerkz with other implementations (AspectJ)?

Very rough comparison is here: http://kgionline.com/articles/aop_1/aop1.jsp#aspectwerkz

I ported your bench to JBoss AOP. Here's the results:     [java] Direct call::Test cycle took:30 ms with one call takes: 3.0E-5 ms. Counter:1000000     [java] Using CGLib::Test cycle took:201 ms with one call takes: 2.01E-4 ms. Counter:1000000     [java] Using JBoss AOP::Test cycle took:261 ms with one call takes: 2.61E-4 ms. Counter:1000000I sent Konstantin the code, so its up to him if he wants to post it.Bill

Thanks for code Bill, it is there http://kgionline.com/articles/aop_1/aop1.jsp#jboss-aop
and demonstrates pretty good performance indeed.
But your example requires post-compillation and none of others require it. That makes JBoss-AOP slightly less convenient for use IMO.
I have added HiveMind to the mix too and it demonstrates almost the same performance as JBoss-AOP :)

But your example requires post-compillation and none of others require it. That makes JBoss-AOP slightly less convenient for use IMO.I have added HiveMind to the mix too and it demonstrates almost the same performance as JBoss-AOP :)

We support load time transformation.

http://docs.jboss.org/aop/aspect-framework/reference/en/html/running.html#d0e2536

Konstantin,

I saw that you used AspectWerkz 1.0-beta2 in your test.
So now I think, Just to be fair, you need to do the same test with AspectWerkz v1.0 final and publish the new results.
This will make your comparison much more valid.

Guy.

Konstantin,I saw that you used AspectWerkz 1.0-beta2 in your test.So now I think, Just to be fair, you need to do the same test with AspectWerkz v1.0 final and publish the new results.This will make your comparison much more valid.Guy.

Results from 06-Nov-2004 (last ones) were measured with AspectWerkz v1.0 final, sorry I did not updated text.

Take glance at source ( http://kgionline.com/articles/aop_1/aop1.jsp ) and run it yourself on your machine.
I ran tests on my SuSE 9.1 (kernel 2.6) Athlon 2000+ 512MB RAM

Jonas,

congratulations. Exceptional work!

-Dmitriy.

1+

Congrats to Alex and Jonas and the members of the AW mailing list (like the_mindstorm) who provide additional help behind the scenes.

Congratulations. AW is much better than AspectJ because it does not alter Java syntax.
I am especially impressed by multitude of JVM plugins and classloader hacks.

Keep up the good job.

Sun, please fix classloader architecture somehow and make classloader nightmare the thing of distant past.

Sun, please fix classloader architecture somehow and make classloader nightmare the thing of distant past.

I don't know exactly what you need but class redefinition (instrumentation) is available in jdk 1.5. Look for java.lang.instrument package.

Sun, please fix classloader architecture somehow and make classloader nightmare the thing of distant past.

I don't know exactly what you need but class redefinition (instrumentation) is available in jdk 1.5. Look for java.lang.instrument package.

I need clear and straightforward classloading architecture:
- Thread.getCurrentClassloader() should be only way to obtain classloader;
- there should be virtually one Classloader that operates upon one classpath with using appropriate plugging to interpret classpath entries; same way as Driver manager finds appropriate JDBC driver;
- Classloading must not break language semantic: instanceof should return true for instances of the same class from the same source even loaded by different classloaders;

if you are interested in AspectWerkz you may also be interested in this recent interview to its creator.

Cheers.