Re: [aspectj-users] JoinPoint SourceLocation vs. Stack Trace Interigatio

[Matthew Webster <matthew_webster@xxxxxxxxxx>]

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