[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-users] JoinPoint SourceLocation vs. Stack Trace Interigation


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/



Gregory Kedge <greg@xxxxxxxxxx>
Sent by: aspectj-users-bounces@xxxxxxxxxxx

04/09/2006 15:12

Please respond to
aspectj-users@xxxxxxxxxxx

To
aspectj-users@xxxxxxxxxxx
cc
Subject
Re: [aspectj-users] JoinPoint SourceLocation vs. Stack        Trace        Interigation





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/

Gregory Kedge <greg@xxxxxxxxxx>
Sent by:
aspectj-users-bounces@xxxxxxxxxxx

03/09/2006 19:08

Please respond to
aspectj-users@xxxxxxxxxxx


To
aspectj-users@xxxxxxxxxxx
cc
Subject
Re: [aspectj-users] JoinPoint SourceLocation vs. Stack Trace        Interigation







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