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
|
