Invokers, AOP and performance
timfox Nov 28, 2002 8:27 AMFirstly, apologies for cross-posting, and for butting-in on a developer's forum, when I am not a developer.
I realise I am breaking the etiquetee, and probably deserve a flaming for that!
I'm reposting here, my original question from a thread I posted in the Lizzard's corner.
I didn't really wanted to post here and be rude and interrupt you guys, but I'm really curious what you guys who are actually building it think, and I have had some indication that others are thinking the same way as myself.
A quick summary of the post would be:
Concept of interceptors and AOP completely rocks, but worried about the implementation, since it could stink in terms of performance.
Suggestion would be to use byte code engineering (I know Bill seems to be using javassist for some stuff, but not all), to encapsulate the entire invoker stack and weaving through the pointcuts, thus giving kick asss performance.
I realise Bill's code is now just a prototype so please forgive me if I am being a little premature here...
Here's my original post:
I've been sneaking around, listening in to the threads in the developer's Aspects forum.
(The reason I'm posting here is because I didn't want to butt in, and it's a developer's only forum - as a mere mortal compared to the likes of Marc and Rickard I felt a little intimidated I must say)
Anyway... this stuff has been fascinating me for a while, AOP IMO *is* the future and I find it fantastic that Jboss is starting to address it, not very suprised though since JBoss tends to lead the pack anyway in this matters....
It seems to me that whether you want an ejb container or jdo, or logging or other "cross cutting" concerns, they simply become aspects of your objects. This is mind blowing stuff and will place JBoss light years ahead IMO *IF DONE CORRECTLY*.
Now, someone put me straight here. I love JBoss's idea of dynamic interceptors, and I can understand that the ideas for a full-on AOP has come in part from a development of that.
The only thing, that I didn't like about the way interceptors were implemented is that they involved this enormous long, slow call through the stack of invokeNext()....invokeNext()... blah blah, which let's face it guys really slows stuff down.
Now, I know some people, like Dan O'Connor's Mvcsoft overcome this by bypassing your interceptors (his "lightweight" entity concept), anyway this is all a hack (a nice hack but still a hack), and wouldn't be necessary if the interceptors were quicker.
To cut a long story short, I thought to myself, you don't want to go the weblogic route and precompile stubs, but you if you're willing to use a becl tool (which I believe you use anyway in your dynamic proxy implementation), then you can basically use becl plus your container config. info to create a new class at runtime (also hot swappable) that implements your entire interceptor functionality, but without that whole massive slow call throught the interceptor stack, since you've rewritten it all in the same method at run-time.
To all intents and purposes, it looks like you're just dropping the class in and deploying it - if the becl bytecode rewriting could be done quick enough - no-one would ever know the difference, it would be transparent.
Now take your interceptors, enrich them with more "AOP like" functionality, like regular expression matching on method signatures and, and all sorts of other things, and you a serious kick ass system that is not only infinitely flexible, but in terms of speed flys like shit off a shovel.
Anyway, that's just my 2c. I'm sure you guys (Marc, Rickard, Adrian et al) have been around this loop before, and in a way HOW it is done is just an implementation detail, IMO it's really important since even though I LOVE your interceptor stack (I love the idea), i HATE it too since it is soo slow. (
So my questions is: if you're going the AOP route, then are you going to use a chain still, or are you going to "rewrite classes (ie becl)" on the fly? In my mere moral opinion I think the chain would be tooooo slow to be useful.
Only disadvantage I can think of right now of implementing AOP at bytecode level would be in debugging - when your program fails, your source doesn't correspond with the .class files - could make life difficult.
Anyway guys, I'm so happy you are going in this direction, IMO this is definitely the way to go. I just worry about the way you're going to implement it........
Good luck.