Matthew:
Thank you for your reply. I am interesting in making advice code as efficient as possible so that my own advice code's overhead plus the LTW overhead is a tolerable experience. I would hate to have abandoned the convenience of using the LTW because my own advice code was hideously inefficient. e.g.: If I didn't use JoinPoint.Static to obtain SourceLocation (data readily available to my advice like a freshly pressed £ note on the sidewalk whether I use JoinPoint or not) and instead parsed out the output of new Exception().getStackTrace()[1].toString(), I do believe I would have an intolerable situation.
I do understand that the weaving process is a pay-me-now or pay-me-latter unavoidable hit. For me right now, the fact that this an infrequently used tool not intended for production code, I find the LTW extremely attractive. I have been using the tool on a toy program over the weekend. Today I will get a good indication of the impact of LTW'ing a significant program with my aspects, using a aop.xml that only includes classes of interest of course...
BTW: Do you know how JoinPoint.Static is populated if a stack trace is not employed?
Again, thanks for you time.
On Sep 5, 2006, at 5:32 AM, Matthew Webster wrote: Gregory, Your post suggests that we may have our lines crossed. My statement about performance related to the execution of your woven program not the time taken to weave it. These are 2 separate considerations but it is important to remember that your program will be woven in the same way regardless of when the process takes place. The AspectJ compiler ajc (and the Eclipse-based AJDT) is both a compiler and weaver in one. The compiler, which is an extension to the JDT, can compile both Java classes and AspectJ aspects from source to byte-code. The weaver then weaves the classes and aspects together immediately after compilation (compile-time), using JAR/class files and aspectpath/inpath/outjar (binary or post compile-time), or when you program is executed in an appropriately configured runtime environment (load-time). The input, byte-code, and output, woven byte-code, is exactly the same at each stage as is the way you write your aspects. If you are concerned about the execution performance of your woven application then you should test it using either compile- or post compile-time weaving. This allows you to make changes to your aspects and the language features you use and determine the effects. If required you can then deploy load-time weaving that can add an additional performance overhead, typically only when your application starts, which although you can measure cannot be directly influenced by the code you write. Matthew Webster AOSD Project Java Technology Centre, MP146 IBM Hursley Park, Winchester, SO21 2JN, England Telephone: +44 196 2816139 (external) 246139 (internal) Email: Matthew Webster/UK/IBM @ IBMGB, matthew_webster@xxxxxxxxxx http://w3.hursley.ibm.com/~websterm/ As with any performance concern the best course of action is to devise a benchmark, protoype your system and measure it. If the performance is acceptable then you never need worry about how parts of it you didn't write actually work (do you know how the JVM works?). If on the other hand performance is not acceptable then please use this list to either seek advice on language usage or even report a bug. I am hoping that for the most part, my customers (including me) can tolerate using LTW so I am indeed worrying myself over pre-optimization [when perhaps I should just always have ready to go pre-compiled classes...]. I don't know how the JVM works, but I do get a lot of understanding on how the JDK works through source grokking (eyeballing or debug stepping). By understanding the JDK, I have developed much better techniques in efficiently extricating the services provided by the JDK. I am guessing that I would find many answers to technique and behavior grokking AspectJ source. Is there an plan to create a jar ball of AspectJ source? - If you use thisJoinPoint within a piece of advice to access only static information e.g. source location then the compiler will automatically substitute thisJoinPointStaticPart instead - If you use thisJoinPointStaticPart then no object will be created after the initialization of you program (unlike Exception.getStackTrace() which creates many objects whose GC may severely affect performance) These two valuable incites make sense for compilation weaving and are very nice to know should LTW become intolerable. The tool that I am creating is attempting to save time finding the source locations where certain objects are created and used; an infrequent task that when needed, needs to be able to transpire quicker than manual grokking. With the previous points you have made, I believe that you are saying that if performance is intolerable with LTW, it may be best to move into a pre-compile mode. All I am attempting to do is code up the most efficient aspects prior to throwing in the LTW proverbial towel. Perhaps what you are trying to say is that there is little that I can do in aspect crafting, silly or otherwise, to make any significant impact on weaving performance? - AspectJ generates all the static information needed for thisJoinPointStaticPart when it weaves you class Thank you for confirming my assumption there. If the static part is always generated, regardless if advice makes use of a JoinPoint (static or otherwise), it would be enormously silly to use a stack trace to obtain that information. Advice written like that would have to seek assistance from the Ministry of Silly Walks. :-) Now, does anybody know how the source information is extricated from the class files for storage into JoinPoint.StaticPart? I would still like to know how to do that if a stack trace is not needed... On Sep 4, 2006, at 4:36 AM, Matthew Webster wrote:
Gregory, As with any performance concern the best course of action is to devise a benchmark, protoype your system and measure it. If the performance is acceptable then you never need worry about how parts of it you didn't write actually work (do you know how the JVM works?). If on the other hand performance is not acceptable then please use this list to either seek advice on language usage or even report a bug. Some other things that you might like to know: - If you use thisJoinPoint within a piece of advice to access only static information e.g. source location then the compiler will automatically substitute thisJoinPointStaticPart instead - If you use thisJoinPointStaticPart then no object will be created after the initialization of you program (unlike Exception.getStackTrace() which creates many objects whose GC may severely affect performance) - AspectJ generates all the static information needed for thisJoinPointStaticPart when it weaves you class Matthew Webster AOSD Project Java Technology Centre, MP146 IBM Hursley Park, Winchester, SO21 2JN, England Telephone: +44 196 2816139 (external) 246139 (internal) Email: Matthew Webster/UK/IBM @ IBMGB, matthew_webster@xxxxxxxxxx http://w3.hursley.ibm.com/~websterm/
>> Prior to JoinPoint, I was unaware of any other Java mechanism to >> obtain file location information beyond the stack trace. > > The stack trace gets the file location information from attributes in > the .class file put there by ... the compiler. The source location > is generated staticly by the compiler at compile-time so there is *no* > cost to generate it at run time. I knew that, but I don't know how to obtain that information out the .class file other than using the very expensive (as Eric AND I made point of) stack trace. And I still don't know how JoinPoint.StaticPart populates its data... But I think you are inferring is that whatever AspectJ is doing to obtain the JoinPoint.StaticPart data, they are not using a stack trace to obtain that data. Cool. Is my assumption correct that the JoinPoint.StaticPart is populated whether I use it in the advice or not? [I have looked at the source in CVS online and have only ferreted out JoinPoint interfaces, not the implementations...] > As for generating stack traces, Eric Bodden already stated that it > was one of the most expensive operations in Java (no less so of late), > as you can imagine if you think about it. I know its expensive. I promise I won't use it. I will use JoinPoint.Static. How does JoinPoint.StaticPart extricate the class data to populate it? >> Sorry if I am over obsessing on this but, asking helps me learn AND >> move on... :-} > > Two (very smart) people replied with the answer to your original > question > within 45 minutes (I love this list...). That was indeed impressive. > But then it seems you didn't try or > research their answers to validate them for yourself. Their > answers were terse > because this question is one that one can teach oneself by reading the > documentation (I hate this list...). I have poured over the documentation. All I can say at this point is that it is a slog. I finally came up with a crosscutting problem to solve as a conduit to learning and appreciating AOP. So, I am doing this without an AOP course or having purchased the dated AspectJ in Action. I am starting from the premise that annotation style using the LTW will work best for me to debug with while using a non-Eclipse IDE to learn/develop. So, non-annotations references that may better elucidate fundamental AOP principles make the mapping to annotations a challenge. > I'm glad to see folks using annotation style. I realize the docs > and the > implementation aren't entirely tailored for that style, so any > feedback > you have there can help us make it easier for folks who come after > you. If Ramnivas L. is the be-end-all of writing for the beginner, light a fire under he and his publisher to update ApectJ in Action using annotations. In lieu of that happening soonish, the only document that I can find that is annotations specific quick5.pdf that is included in the download jar. Any recommendation on a more pervasive reference, please offer. Google is only coming up with small one time examples showing the "possibilities" and http://www.eclipse.org/ aspectj/doc/released/adk15notebook/ doesn't do it for me... > Their answers were terse because this question is one that one can > teach oneself > by reading the documentation (I hate this list...). > ... > I'm glad to see folks using annotation style. I realize the docs > and the > implementation aren't entirely tailored for that style, Tough list. :-\ > > Thanks - > Wes _______________________________________________ aspectj-users mailing list aspectj-users@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/aspectj-users _______________________________________________ aspectj-users mailing list aspectj-users@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/aspectj-users _______________________________________________ aspectj-users mailing list aspectj-users@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/aspectj-users
_______________________________________________ aspectj-users mailing list
|