Nabble - AspectJ

Are you loadtime weaving? What do your include/exclude patterns look like?

2009-12-05T14:33:55Z

At the moment AspectJ optimizes for only a couple of include/exclude
patterns - I'd like to optimize some more and am collecting input on
what patterns people are using?

Here is an example aop.xml file

<aspectj>
<aspects>
<aspect name="Logging"/>
</aspects>
<weaver options="-verbose">
<include within="javax..*"/>
<include within="org.aspectj.*"/>
<include within="@NoWeave *"/>
<exclude within="bar.*"/>
</weaver>
</aspectj>

I'm interested in the kind of thing you might be specifying as within
patterns in the weaver include/exclude settings.

AspectJ currently optimizes for com.foo.* and com.foo..* style
patterns *only*. Are you:
- using annotations?
- using compound patterns with AND/OR/NOT?
- doing something funky?

I guess I'm also interested in how many you have - just a couple? 10? 50?

Let me know and if there look like some very popular patterns that
seem worth trying to speed up, I'll try and do so for 1.6.7

cheers,
Andy
_______________________________________________
aspectj-users mailing list
aspectj-users@...
https://dev.eclipse.org/mailman/listinfo/aspectj-users

From forum: AspectJ - users

Re: jenia - capture method

2009-12-04T06:31:16Z

Hi Jenia,
the method itself can be accessed using the AspectJ reflection API :

pointcut anymethod() : call(* * *.*(..));

before() : anymethod() {
MethodSignature sig =
(MethodSignature)thisJoinPointStaticPart.getSignature();
Method m = sig.getMethod();
// Use m as you want to
}

Hope this helps,
Simone

ivlev jenia wrote:

> I want to capture the method for which the joinpoint is executed.
>
> pointcut anymethod(method m):call(* * *.*(..))&&target(m)
> But this doesnt work ofcourse.
> So my question is: how can I capture the method?
> Thank you for your kind concern.
> Jenia
>
> ------------------------------------------------------------------------
> The new Internet Explorer® 8 - Faster, safer, easier. Optimized for
> Yahoo! *Get it Now for Free!*
> <http://downloads.yahoo.com/ca/internetexplorer/>
> ------------------------------------------------------------------------
>
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@...
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>

--
Simone Gianni CEO Semeru s.r.l. Apache Committer
http://www.simonegianni.it/

_______________________________________________
aspectj-users mailing list
aspectj-users@...
https://dev.eclipse.org/mailman/listinfo/aspectj-users

From forum: AspectJ - users

jenia - capture method

2009-12-03T18:36:50Z

I want to capture the method for which the joinpoint is executed.

pointcut anymethod(method m):call(* * *.*(..))&&target(m)
But this doesnt work ofcourse.
So my question is: how can I capture the method?
Thank you for your kind concern.
Jenia

The new Internet Explorer® 8 - Faster, safer, easier. Optimized for Yahoo! Get it Now for Free!
_______________________________________________
aspectj-users mailing list
aspectj-users@...
https://dev.eclipse.org/mailman/listinfo/aspectj-users

From forum: AspectJ - users

Re: Generated AjcClosure classes

2009-12-03T14:07:40Z

Hi,

thanks for the code. Half an hour after sending you the mail, and reading more code, I came up with the same solution, basically, which means I was right :).

Cheers,
Silviu
On Dec 3, 2009, at 3:44 PM, Simone Gianni wrote:

> Hi Silviu,
> in Magma I'm using the following :
>
> public class AspectJClassTransformer extends ClassLoader implements
> ClassTransformer, WeavingClassLoader {
> // Various method of a classloader
> // ....
>
> // Implements GeneratedClassHandler.acceptClass
> public void acceptClass(String name, byte[] bytes) {
> System.out.println("AspectJ pushed " + name);
> }
>
> // ....
>
> }
>
> On system out, i see :
>
> AspectJ weaving org.apache.magma.settings.SettingsHolder
> AspectJ pushed org.apache.magma.settings.SettingsHolder$AjcClosure1
> AspectJ pushed org.apache.magma.settings.SettingsHolder$AjcClosure3
> AspectJ pushed org.apache.magma.settings.SettingsHolder$AjcClosure5
> AspectJ pushed org.apache.magma.settings.SettingsHolder$AjcClosure7
> AspectJ pushed org.apache.magma.settings.SettingsHolder$AjcClosure9
>
> So, in a class loader system, the accept method receives closures. I
> don't do anything special with them (except defining them in my current
> classloader). As i said before, I don't know if in an agent the same
> rules apply.
>
> Simone
>
>
>
> Andrica Silviu wrote:
>> Ciao Simone,
>>
>> could you give me a clue on how to catch the newly created closures?
>> I was playing with Aj and its source code, but it seems that no matter what I try I cannot get it to work. The "accept" method I use only catches the original classes, never their closures.
>>
>> Thanks a lot,
>> Silviu
>> On Dec 2, 2009, at 9:54 PM, Simone Gianni wrote:
>>
>>
>>> Andy Clement wrote:
>>>
>>>> You know, I'm on the verge of creating such a thing in AspectJ
>>>> itself... I would be interested to here about your approach and how
>>>> you know when to invalidate the cache, and what are you using as the
>>>> cache key (some combination of the class itself hashed or something,
>>>> plus the combination of aspects defined at the time, hashed or
>>>> something?)
>>>>
>>>>
>>> Hi Andy and Silviu,
>>> I'm very happy you're planning such an improvement!
>>>
>>> I also tried to cache LTW classes, but did not find a way to invalidate
>>> the right classes : when an aspect was somehow added, removed or
>>> modified, I invalidated the entire cache and started from scratch, even
>>> if probably only a few classes need reweaving. If a single comma was
>>> added in a string in a single ITD, despite being a single byte
>>> modification in a single class file, I had no option that reweaving
>>> everything.
>>>
>>> I tried to use AspectJ matching system to know which aspects applied to
>>> a given class, so that I could invalidate only classes affected by a
>>> changed aspect. I can't remember how much I managed to do this, but even
>>> if I managed to, I could not know if a changed aspect only modified it's
>>> advice implementation or also it's "matching part", that is point cuts.
>>>
>>> If however it was possible to know whether an aspect changed its point
>>> cuts or only its advice implementation (which happens most of the time,
>>> especially when ITDs are used), it could be possible to invalidate only
>>> classes that were matched by that aspect, and invalidate the full cache
>>> only when the point cuts are changed.
>>>
>>> Applying the existing matching system is not a valid solution, cause
>>> matching is the slowest part of the weaving process, and having to use
>>> it to decide whether to invalidate a class or not makes the cache slower
>>> than a full reweave.
>>>
>>> So, I think, the cache should save, as a state, not only the hashes of
>>> defined aspects, but hashes of the point cuts of defined aspects. If
>>> those are not changed (implicitly, no aspect has been added or removed),
>>> then the model is still valid, and only classes affected by the modified
>>> aspects needs to be reweaved to apply modified advice implementation.
>>>
>>>> If AspectJ did this itself then the only user configuration would be a
>>>> place to keep these woven classes so that they can be retrieved later.
>>>> Do you have any specific requirements for the cache in your scenario?
>>>> (or does anyone else reading this have requirements on a cache like
>>>> this?)
>>>>
>>>>
>>> This would be great and enough for my needs. Later probably a listener
>>> on the cache could be useful, to integrate it in the case of a chain of
>>> transforming classloaders like when there is AspectJ + JPA or similar
>>> situations.
>>>
>>> Simone
>>>
>>> --
>>> Simone Gianni CEO Semeru s.r.l. Apache Committer
>>> http://www.simonegianni.it/
>>>
>>> _______________________________________________
>>> aspectj-users mailing list
>>> aspectj-users@...
>>> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>>>
>>
>> _______________________________________________
>> aspectj-users mailing list
>> aspectj-users@...
>> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>>
>
>
> --
> Simone Gianni CEO Semeru s.r.l. Apache Committer
> http://www.simonegianni.it/
>
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@...
> https://dev.eclipse.org/mailman/listinfo/aspectj-users

_______________________________________________
aspectj-users mailing list
aspectj-users@...
https://dev.eclipse.org/mailman/listinfo/aspectj-users

From forum: AspectJ - users

Re: Memory consumption problems

2009-12-03T14:03:15Z

Hi Tim,

I'll grab those files when I can (rapidshare isn't playing ball right
now). 1.6.7 dumps are what I need, too much has changed since 1.6.2
so they wouldn't be as much help.

> I did, and the heap size even increased compared to a version of 1.6.6.
> The Full GC issues we're having right now are with version 1.6.2.

The changes for 1.6.7 may increase some temporary memory usage but all
the newly cached 'stuff' is only reachable via weak references and so
collectable whenever the system needs the memory. At least that is
how I see it all behaving in my test setup (tomcat plus SpringTravel
web application - the spring aspect library is in the mix too).

> What are ITD's?

Intertype declarations, sometimes called static crosscutting (where
advice/pointcuts are dynamic crosscutting). For example:

aspect X {
int Foo.x // create a new field in Foo called 'x'
int Foo.m() { return 42; } // create a new method in Foo returning an int
}

> For one module we're just using @Configurable and Spring aspects on domain
> classes.
> For another module we have aspects for logging and accounting and stuff.
> We can see the symptoms when we just deploy the module with @Configurable
> already.
> It just gets worse when other modules are deployed (because this just means
> more classes to be contained in the World map I think)

Certainly as more gets woven, more will make it into the world, but it
should all be garbage collectable. It can depend how your VM treats
references - I see a lot of variation. In my testing I attach a
jconsole/yourkit and keep battering 'Run GC' until I finally see them
all going, but that can take up to a minute or 30/40 GCs (stupid
thing). However, if you say the heap is showing them anchored from
the root then something else must be up. I'll take a look.

Did you think you did or did not want to weave the JSPs? I'm still
toying with adding the necessary options to prevent weavers for
certain types of classloader.

Andy
_______________________________________________
aspectj-users mailing list
aspectj-users@...
https://dev.eclipse.org/mailman/listinfo/aspectj-users

From forum: AspectJ - users

Re: AspectJ and code coverage?

2009-12-03T11:54:05Z

I will be most grateful Simone! Enjoy your holiday :)

2009/12/3 Simone Gianni <simoneg@...>

Hi Wim,
I didn't forget about you, I have "Add an example pom.xml for AspectJ + Cobertura on aj wiki" on my todo list, but found no time yet to do it .. hopefully I'll manage to find time on Monday cause it's holiday here in Italy.

Simone

Wim Deblauwe wrote:

Would it be possible to provide a sample project with pom.xml on how to do it? Maybe this can be added to some wiki if there is one of aspectj or you can add it to the mavenuser wiki?

2009/11/30 Simone Gianni <simoneg@... <mailto:simoneg@...>>

Hi Wim,
I'm using Maven2 + AspectJ + Cobertura successfully, but there are
a few caveats.

I'm currently weaving first and then instrumenting with cobertura.
If I remember correctly, I'm cobertura-instrumenting the entire
jar. I could do this cause in our setup coverage reports are
executed in a separate step, when generating the project site.
Since AspectJ inlines a few calls inside methods using "line 1" of
the target class file, or the first line of the method, you'll see
cobertura reporting a lot of hits on this lines, even if they does
not contain any apparently useful code. This may confuse who is
used to cobertura reports and not aware of AspectJ internals, but
can be interpreted as useful informations cause you may understand
how many instructions are executed because of AspectJ aspect lookup.

I also set up a "load time cobertura instrumentation", that goes
in pair with load time weaving, but in that case if an entire
class does not get loaded, cobertura knows nothing about it, which
alters the global coverage measurements, so I dropped it.

If you have a specific error, I can try to investigate it.

Simone

Wim Deblauwe wrote:

Hi,

is there anybody who is using AspectJ with a code coverage
tool. We are using Cobertura and Maven2, but that does not
work when you start to add an aspect to your code and you need
to use the ajc compiler. I just checked with Atlassian and
Clover cannot seem to manage it according to them. Anybody
knows a workaround? I don't want to have code coverage on the
aspect, I just don't want to loose the coverage on my regular
java classes.

regards,

Wim
------------------------------------------------------------------------

_______________________________________________
aspectj-users mailing list
aspectj-users@... <mailto:aspectj-users@...>

https://dev.eclipse.org/mailman/listinfo/aspectj-users

-- Simone Gianni CEO Semeru s.r.l. Apache Committer
http://www.simonegianni.it/

_______________________________________________
aspectj-users mailing list
aspectj-users@... <mailto:aspectj-users@...>

https://dev.eclipse.org/mailman/listinfo/aspectj-users

------------------------------------------------------------------------

_______________________________________________
aspectj-users mailing list
aspectj-users@...
https://dev.eclipse.org/mailman/listinfo/aspectj-users

--
Simone Gianni CEO Semeru s.r.l. Apache Committer
http://www.simonegianni.it/

_______________________________________________
aspectj-users mailing list
aspectj-users@...
https://dev.eclipse.org/mailman/listinfo/aspectj-users

_______________________________________________
aspectj-users mailing list
aspectj-users@...
https://dev.eclipse.org/mailman/listinfo/aspectj-users

From forum: AspectJ - users

Re: AspectJ and code coverage?

2009-12-03T06:49:52Z

Hi Wim,
I didn't forget about you, I have "Add an example pom.xml for AspectJ +
Cobertura on aj wiki" on my todo list, but found no time yet to do it ..
hopefully I'll manage to find time on Monday cause it's holiday here in
Italy.

Simone

Wim Deblauwe wrote:

> Would it be possible to provide a sample project with pom.xml on how
> to do it? Maybe this can be added to some wiki if there is one of
> aspectj or you can add it to the mavenuser wiki?
>
> 2009/11/30 Simone Gianni <simoneg@... <mailto:simoneg@...>>
>
> Hi Wim,
> I'm using Maven2 + AspectJ + Cobertura successfully, but there are
> a few caveats.
>
> I'm currently weaving first and then instrumenting with cobertura.
> If I remember correctly, I'm cobertura-instrumenting the entire
> jar. I could do this cause in our setup coverage reports are
> executed in a separate step, when generating the project site.
> Since AspectJ inlines a few calls inside methods using "line 1" of
> the target class file, or the first line of the method, you'll see
> cobertura reporting a lot of hits on this lines, even if they does
> not contain any apparently useful code. This may confuse who is
> used to cobertura reports and not aware of AspectJ internals, but
> can be interpreted as useful informations cause you may understand
> how many instructions are executed because of AspectJ aspect lookup.
>
> I also set up a "load time cobertura instrumentation", that goes
> in pair with load time weaving, but in that case if an entire
> class does not get loaded, cobertura knows nothing about it, which
> alters the global coverage measurements, so I dropped it.
>
> If you have a specific error, I can try to investigate it.
>
> Simone
>
>
>
> Wim Deblauwe wrote:
>
> Hi,
>
> is there anybody who is using AspectJ with a code coverage
> tool. We are using Cobertura and Maven2, but that does not
> work when you start to add an aspect to your code and you need
> to use the ajc compiler. I just checked with Atlassian and
> Clover cannot seem to manage it according to them. Anybody
> knows a workaround? I don't want to have code coverage on the
> aspect, I just don't want to loose the coverage on my regular
> java classes.
>
> regards,
>
> Wim
> ------------------------------------------------------------------------
>
>
>
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@... <mailto:aspectj-users@...>
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>
>
>
>
> --
> Simone Gianni CEO Semeru s.r.l. Apache Committer
> http://www.simonegianni.it/
>
>
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@... <mailto:aspectj-users@...>
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@...
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>

From forum: AspectJ - users

Re: Generated AjcClosure classes

2009-12-03T06:44:59Z

Hi Silviu,
in Magma I'm using the following :

public class AspectJClassTransformer extends ClassLoader implements
ClassTransformer, WeavingClassLoader {
// Various method of a classloader
// ....

// Implements GeneratedClassHandler.acceptClass
public void acceptClass(String name, byte[] bytes) {
System.out.println("AspectJ pushed " + name);
}

// ....

}

On system out, i see :

AspectJ weaving org.apache.magma.settings.SettingsHolder
AspectJ pushed org.apache.magma.settings.SettingsHolder$AjcClosure1
AspectJ pushed org.apache.magma.settings.SettingsHolder$AjcClosure3
AspectJ pushed org.apache.magma.settings.SettingsHolder$AjcClosure5
AspectJ pushed org.apache.magma.settings.SettingsHolder$AjcClosure7
AspectJ pushed org.apache.magma.settings.SettingsHolder$AjcClosure9

So, in a class loader system, the accept method receives closures. I
don't do anything special with them (except defining them in my current
classloader). As i said before, I don't know if in an agent the same
rules apply.

Simone

Andrica Silviu wrote:

> Ciao Simone,
>
> could you give me a clue on how to catch the newly created closures?
> I was playing with Aj and its source code, but it seems that no matter what I try I cannot get it to work. The "accept" method I use only catches the original classes, never their closures.
>
> Thanks a lot,
> Silviu
> On Dec 2, 2009, at 9:54 PM, Simone Gianni wrote:
>
>
>> Andy Clement wrote:
>>
>>> You know, I'm on the verge of creating such a thing in AspectJ
>>> itself... I would be interested to here about your approach and how
>>> you know when to invalidate the cache, and what are you using as the
>>> cache key (some combination of the class itself hashed or something,
>>> plus the combination of aspects defined at the time, hashed or
>>> something?)
>>>
>>>
>> Hi Andy and Silviu,
>> I'm very happy you're planning such an improvement!
>>
>> I also tried to cache LTW classes, but did not find a way to invalidate
>> the right classes : when an aspect was somehow added, removed or
>> modified, I invalidated the entire cache and started from scratch, even
>> if probably only a few classes need reweaving. If a single comma was
>> added in a string in a single ITD, despite being a single byte
>> modification in a single class file, I had no option that reweaving
>> everything.
>>
>> I tried to use AspectJ matching system to know which aspects applied to
>> a given class, so that I could invalidate only classes affected by a
>> changed aspect. I can't remember how much I managed to do this, but even
>> if I managed to, I could not know if a changed aspect only modified it's
>> advice implementation or also it's "matching part", that is point cuts.
>>
>> If however it was possible to know whether an aspect changed its point
>> cuts or only its advice implementation (which happens most of the time,
>> especially when ITDs are used), it could be possible to invalidate only
>> classes that were matched by that aspect, and invalidate the full cache
>> only when the point cuts are changed.
>>
>> Applying the existing matching system is not a valid solution, cause
>> matching is the slowest part of the weaving process, and having to use
>> it to decide whether to invalidate a class or not makes the cache slower
>> than a full reweave.
>>
>> So, I think, the cache should save, as a state, not only the hashes of
>> defined aspects, but hashes of the point cuts of defined aspects. If
>> those are not changed (implicitly, no aspect has been added or removed),
>> then the model is still valid, and only classes affected by the modified
>> aspects needs to be reweaved to apply modified advice implementation.
>>
>>> If AspectJ did this itself then the only user configuration would be a
>>> place to keep these woven classes so that they can be retrieved later.
>>> Do you have any specific requirements for the cache in your scenario?
>>> (or does anyone else reading this have requirements on a cache like
>>> this?)
>>>
>>>
>> This would be great and enough for my needs. Later probably a listener
>> on the cache could be useful, to integrate it in the case of a chain of
>> transforming classloaders like when there is AspectJ + JPA or similar
>> situations.
>>
>> Simone
>>
>> --
>> Simone Gianni CEO Semeru s.r.l. Apache Committer
>> http://www.simonegianni.it/
>>
>> _______________________________________________
>> aspectj-users mailing list
>> aspectj-users@...
>> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>>
>
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@...
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>

From forum: AspectJ - users

Re: Memory consumption problems

2009-12-03T02:26:09Z

Andy Clement wrote:

> Analyzing the heapdumps so far has also pointed out a lot of AspectJ classes
> taking up a LOT of memory.
> There are even BcelObjectTypes referring to compiled jsp's.

In a heap dump it is important to look at those types anchored via
hard references from root and not just look at the heap as a whole and
look how many BcelObjectTypes there are, since many may be weakly
referenced - are all the BcelObjectTypes anchored from root?

I'll try and gmail you the heap dump we took with jmap.
The way we "analyzed" it with MAT, is we got references to BcelObjectTypes, and then showed path to gc root excluding weak/phantom references.
I'm very new to all this stuff, so chances are I'm wrong about my Full GC theory :)

Andy Clement wrote:

>
> I have been suspecting aop.xml merging for this behaviour, but sort of ruled
> it out by getting rid of aop.xml in spring-agents.jar (which is found in the
> web-inf/lib of one of our modules deployed on the appserver, along with a
> sub-module jar that contains _our_ aop.xml with the correct inclusions and
> exclusions).
> My theory is the map just keeps growing along with how many classes are
> loaded, and then the memory just isn't enough for loading in everything and
> crashes.
I see. The spring aop.xml does define some sophisticated aspects that
may well be getting into the mix here.

> I had found your blog post about the performance gain in 1.6.7 and was
> hopeful, but it didn't solve our problem (loading classes that should be
> excluded).

So you tried running on a very recent 1.6.7 dev build? If you want
to, I am more than willingly to work with you on this issue - if you
are running with a very recent AspectJ dev build and were able to
share dumps with me, I'll sort it out. Either email them to me or
zip/attach them to that bug report. yourkit is my preferred format,
but I can deal with pretty much anything. It would be interesting to
know if you are using a lot of ITDs, or simply advice? Since that
makes a difference on what gets held onto in a World.

I did, and the heap size even increased compared to a version of 1.6.6.
The Full GC issues we're having right now are with version 1.6.2.

What are ITD's?

For one module we're just using @Configurable and Spring aspects on domain classes.
For another module we have aspects for logging and accounting and stuff.
We can see the symptoms when we just deploy the module with @Configurable already.
It just gets worse when other modules are deployed (because this just means more classes to be contained in the World map I think)

Andy Clement wrote:

> Do you think maybe the placement of the aop.xml, and/or the placement of
> aspectjweaver.jar may be the cause?

It could be the aop.xml merges causing you a headache, or it could
simply be the inability to say "I DONT WANT A DAMN WEAVER FOR THOSE
JSP CLASSLOADERS" :) An ability to filter which classloaders you want
a weaver for has been talked about before but there is currently no
mechanism. Do you believe you want to weave the result of JSP
compilation? I think there can be a ton of jsp classloaders in a
system, coming and going regularly. However, although a lot of memory
may be getting used, I don't understand why you are eventually running
out since care has been taken that once loaders go then weavers
attached to them also vanish. AspectJ shouldn't really be able to
cause PermGen issues by itself as it doesn't create and manage
classloaders itself, however *if* there is a bug and it is anchoring a
classloader that the system has already discarded, that could lead to
a permgen problem. In your heap dump, take a look for classloader
instances and whether any are being hard referenced through AspectJ.

> I feel like I've tried everything, so today I was converting all our modules
> to compile time weaving. Which impacts our development process and increases
> build-time and what not. But it works, and just loads the strictly necessary
> woven classes.

Latest aspectj has really improved some build times due to improved
matching algorithms. I heard AJDT build time was down from 55 seconds
to 38 seconds - both of which are low, but that saving should scale up
to any size system that is doing a decent amount of weaving.

> I also feel like I'm kind of hi-jacking this thread. Whoopsie.

No problem - we can continue this discussion on the mailing list, in
bugzilla or on email. up to you :)

cheers,
Andy
_______________________________________________
aspectj-users mailing list
aspectj-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/aspectj-users

From forum: AspectJ - users

Re: priviledged aspect

2009-12-02T19:37:08Z

This is really a Java reflection API question. Check http://java.sun.com/javase/6/docs/api/java/lang/reflect/AccessibleObject.html#setAccessible(boolean) to access non-public members. Also, if you go that route, you don't need your aspect to be marked at privileged.

-Ramnivas

On Wed, Dec 2, 2009 at 6:40 PM, ivlev jenia <jenia2009@...> wrote:

Hello.
From a privileged AspectJ class I want to access the private fields of an object; lets call this object x.
To do this I would do x.fieldname.
Now I have fieldname stored in a String, lets call it y.
So how can I do the equivalent of x.y ?
Also I tried to go x.getClass().getField(y). This works fine for public fields, I need to do it for private fields.

Thank you for your kind concner.
Jenia Ivlev

The new Internet Explorer® 8 - Faster, safer, easier. Optimized for Yahoo! Get it Now for Free!

_______________________________________________
aspectj-users mailing list
aspectj-users@...
https://dev.eclipse.org/mailman/listinfo/aspectj-users

_______________________________________________
aspectj-users mailing list
aspectj-users@...
https://dev.eclipse.org/mailman/listinfo/aspectj-users

From forum: AspectJ - users

priviledged aspect

2009-12-02T18:40:36Z

Hello.
From a privileged AspectJ class I want to access the private fields of an object; lets call this object x.
To do this I would do x.fieldname.
Now I have fieldname stored in a String, lets call it y.
So how can I do the equivalent of x.y ?
Also I tried to go x.getClass().getField(y). This works fine for public fields, I need to do it for private fields.

Thank you for your kind concner.
Jenia Ivlev

From forum: AspectJ - users

Re: Generated AjcClosure classes

2009-12-02T15:15:27Z

I would like to point out that in a production environment detecting
complex changes across runs is not necessarily a big requirement once
one can invalidate the cache easily during deployment (not
hot-deployment because that is not a managed production environment in
anyone book). The purpose of the cache should be to improve the start-up
time - this is paramount. One can easily relax some checks as the
assumption is that nothing has changed outside a change request (& work
order) which would have lead to the cache been invalidated (deleted from
the file system) by operations. That said one does need to still handle
the case of a class being loaded across different classloaders so a key
on the class name or bytecode along is insufficient. JXInsight actually
matches a class loaded by different classloaders if the class image is
the same and the digest generated for a classloader hierarchy (based
static contexts) is also the same.

Andy is doing some great work lately on speeding things up so maybe the
benefits of a cache will diminish over time to some degree.

One thing which I do like about our approach is that we can front the
weaver with a configuration-based class filter which allows us to deploy
generic (pointcuts) aspects libraries and then refine the visibility
externally without needing to package/edit an aop.xml file or change a
aspect class.

Kind regards,

William

On 12/2/09 7:43 PM, William Louth (JINSPIRED.COM) wrote:

> Hi Andy,
>
> You are correct a key based just on the class bytecode is whole-fully
> insufficient at least in the enterprise space because of classloaders
> each of which can have different aspect
> dependencies/libraries/configurations. JXInsight's enhanced AspectJ
> weaver uses cache based on composite-key digests generated for
> classloaders & classes that factors in such additional context
> information. We also enhanced the load-time weaver with other
> capabilities including class filtering, class differencing,
> diagnostics, profiling,.... We have had this capability for more than
> 1 1/2 years.
>
> Kind regards,
>
> William
>
>

_______________________________________________
aspectj-users mailing list
aspectj-users@...
https://dev.eclipse.org/mailman/listinfo/aspectj-users

From forum: AspectJ - users

Re: Generated AjcClosure classes

2009-12-02T14:52:13Z

Ciao Simone,

could you give me a clue on how to catch the newly created closures?
I was playing with Aj and its source code, but it seems that no matter what I try I cannot get it to work. The "accept" method I use only catches the original classes, never their closures.

Thanks a lot,
Silviu
On Dec 2, 2009, at 9:54 PM, Simone Gianni wrote:

> Andy Clement wrote:
>> You know, I'm on the verge of creating such a thing in AspectJ
>> itself... I would be interested to here about your approach and how
>> you know when to invalidate the cache, and what are you using as the
>> cache key (some combination of the class itself hashed or something,
>> plus the combination of aspects defined at the time, hashed or
>> something?)
>>
> Hi Andy and Silviu,
> I'm very happy you're planning such an improvement!
>
> I also tried to cache LTW classes, but did not find a way to invalidate
> the right classes : when an aspect was somehow added, removed or
> modified, I invalidated the entire cache and started from scratch, even
> if probably only a few classes need reweaving. If a single comma was
> added in a string in a single ITD, despite being a single byte
> modification in a single class file, I had no option that reweaving
> everything.
>
> I tried to use AspectJ matching system to know which aspects applied to
> a given class, so that I could invalidate only classes affected by a
> changed aspect. I can't remember how much I managed to do this, but even
> if I managed to, I could not know if a changed aspect only modified it's
> advice implementation or also it's "matching part", that is point cuts.
>
> If however it was possible to know whether an aspect changed its point
> cuts or only its advice implementation (which happens most of the time,
> especially when ITDs are used), it could be possible to invalidate only
> classes that were matched by that aspect, and invalidate the full cache
> only when the point cuts are changed.
>
> Applying the existing matching system is not a valid solution, cause
> matching is the slowest part of the weaving process, and having to use
> it to decide whether to invalidate a class or not makes the cache slower
> than a full reweave.
>
> So, I think, the cache should save, as a state, not only the hashes of
> defined aspects, but hashes of the point cuts of defined aspects. If
> those are not changed (implicitly, no aspect has been added or removed),
> then the model is still valid, and only classes affected by the modified
> aspects needs to be reweaved to apply modified advice implementation.
>> If AspectJ did this itself then the only user configuration would be a
>> place to keep these woven classes so that they can be retrieved later.
>> Do you have any specific requirements for the cache in your scenario?
>> (or does anyone else reading this have requirements on a cache like
>> this?)
>>
> This would be great and enough for my needs. Later probably a listener
> on the cache could be useful, to integrate it in the case of a chain of
> transforming classloaders like when there is AspectJ + JPA or similar
> situations.
>
> Simone
>
> --
> Simone Gianni CEO Semeru s.r.l. Apache Committer
> http://www.simonegianni.it/
>
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@...
> https://dev.eclipse.org/mailman/listinfo/aspectj-users

_______________________________________________
aspectj-users mailing list
aspectj-users@...
https://dev.eclipse.org/mailman/listinfo/aspectj-users

From forum: AspectJ - users

Re: Generated AjcClosure classes

2009-12-02T12:54:36Z

Andy Clement wrote:
> You know, I'm on the verge of creating such a thing in AspectJ
> itself... I would be interested to here about your approach and how
> you know when to invalidate the cache, and what are you using as the
> cache key (some combination of the class itself hashed or something,
> plus the combination of aspects defined at the time, hashed or
> something?)
>
Hi Andy and Silviu,
I'm very happy you're planning such an improvement!

I also tried to cache LTW classes, but did not find a way to invalidate
the right classes : when an aspect was somehow added, removed or
modified, I invalidated the entire cache and started from scratch, even
if probably only a few classes need reweaving. If a single comma was
added in a string in a single ITD, despite being a single byte
modification in a single class file, I had no option that reweaving
everything.

I tried to use AspectJ matching system to know which aspects applied to
a given class, so that I could invalidate only classes affected by a
changed aspect. I can't remember how much I managed to do this, but even
if I managed to, I could not know if a changed aspect only modified it's
advice implementation or also it's "matching part", that is point cuts.

If however it was possible to know whether an aspect changed its point
cuts or only its advice implementation (which happens most of the time,
especially when ITDs are used), it could be possible to invalidate only
classes that were matched by that aspect, and invalidate the full cache
only when the point cuts are changed.

Applying the existing matching system is not a valid solution, cause
matching is the slowest part of the weaving process, and having to use
it to decide whether to invalidate a class or not makes the cache slower
than a full reweave.

So, I think, the cache should save, as a state, not only the hashes of
defined aspects, but hashes of the point cuts of defined aspects. If
those are not changed (implicitly, no aspect has been added or removed),
then the model is still valid, and only classes affected by the modified
aspects needs to be reweaved to apply modified advice implementation.
> If AspectJ did this itself then the only user configuration would be a
> place to keep these woven classes so that they can be retrieved later.
> Do you have any specific requirements for the cache in your scenario?
> (or does anyone else reading this have requirements on a cache like
> this?)
>
This would be great and enough for my needs. Later probably a listener
on the cache could be useful, to integrate it in the case of a chain of
transforming classloaders like when there is AspectJ + JPA or similar
situations.

Simone

--
Simone Gianni CEO Semeru s.r.l. Apache Committer
http://www.simonegianni.it/

_______________________________________________
aspectj-users mailing list
aspectj-users@...
https://dev.eclipse.org/mailman/listinfo/aspectj-users

From forum: AspectJ - users

Re: Generated AjcClosure classes

2009-12-02T10:58:20Z

>> As I say, raise an enhancement request to discuss this.
> How do I do that?

Enhancement requests go here with bugs:
https://bugs.eclipse.org/bugs/enter_bug.cgi?product=AspectJ
_______________________________________________
aspectj-users mailing list
aspectj-users@...
https://dev.eclipse.org/mailman/listinfo/aspectj-users

From forum: AspectJ - users

Re: Generated AjcClosure classes

2009-12-02T10:57:01Z

Hi William,

I knew you had a caching system in JXInsight, I've just not had much
time to explore current strategies and think about solutions to this
problem as including a cache out of the box has only recently become
something I'm thinking of doing. Equinox Aspects also has one for an
OSGi environment.

Andy

2009/12/2 William Louth (JINSPIRED.COM) <william.louth@...>:

> Hi Andy,
>
> You are correct a key based just on the class bytecode is whole-fully
> insufficient at least in the enterprise space because of classloaders each
> of which can have different aspect dependencies/libraries/configurations.
> JXInsight's enhanced AspectJ weaver uses cache based on composite-key
> digests generated for classloaders & classes that factors in such additional
> context information. We also enhanced the load-time weaver with other
> capabilities including class filtering, class differencing, diagnostics,
> profiling,.... We have had this capability for more than 1 1/2 years.
>
> Kind regards,
>
> William
>
>
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@...
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>

_______________________________________________
aspectj-users mailing list
aspectj-users@...
https://dev.eclipse.org/mailman/listinfo/aspectj-users

From forum: AspectJ - users

Re: Memory consumption problems

2009-12-02T10:51:46Z

Hi Tim,

I didn't realise you were actually having real issues right now. So
let's see what we can do about it. I've raised
https://bugs.eclipse.org/bugs/show_bug.cgi?id=296734 to track this
problem.

> We're running on a SunApp, and we include the aspectJWeaver.jar as a JVM
> argument, so as to have the agent for LTW. But what I think is happening, is
> that because we include it as a JVM argument, the adaptor (I think?) is
> loading _all_ classes loaded by the classloader in which AspectJWeaver.jar
> is loaded into, get loaded.

The weaver agent has an option to 'see' all the classes loaded by the
loader it is attached too. And running with -javaagent, nearly all
classloader instances in the system will get a weaver, except for
instances of:

sun.reflect.DelegatingClassLoader

(we don't want to instrument things that loads).

includes/excludes are respected according to the set of aop.xml files
that can be 'seen' from the classloader in question. If running with
debug the weaver instance will tell you which aop.xmls it has seen.

> And since our aop.xml file with inclusions and exclusions is only in a child
> classloader (en EJB or Web), the filtering isn't going on.
> When we look at the GC graph, it keeps adding and removing about 600mb of
> memory every minute or so.
> And eventually leads to FullGC's and PermGen crash.

That seems a lot...but regardless of how much it is, after the weave
of any particular type a whole ton of it should be orphaned for
potential GC (held onto via weak references).

> Analyzing the heapdumps so far has also pointed out a lot of AspectJ classes
> taking up a LOT of memory.
> There are even BcelObjectTypes referring to compiled jsp's.

In a heap dump it is important to look at those types anchored via
hard references from root and not just look at the heap as a whole and
look how many BcelObjectTypes there are, since many may be weakly
referenced - are all the BcelObjectTypes anchored from root?

> My theory is the map just keeps growing along with how many classes are
> loaded, and then the memory just isn't enough for loading in everything and
> crashes.
>
> I have been suspecting aop.xml merging for this behaviour, but sort of ruled
> it out by getting rid of aop.xml in spring-agents.jar (which is found in the
> web-inf/lib of one of our modules deployed on the appserver, along with a
> sub-module jar that contains _our_ aop.xml with the correct inclusions and
> exclusions).

I see. The spring aop.xml does define some sophisticated aspects that
may well be getting into the mix here.

> Documentation I was able to dig up anywhere on the internet was helpful, but
> I still feel like a total idiot about AspectJ.

Me too sometimes :) I didn't write the original LTW stuff so am not a
100% expert on it (yet).

> I had found your blog post about the performance gain in 1.6.7 and was
> hopeful, but it didn't solve our problem (loading classes that should be
> excluded).

So you tried running on a very recent 1.6.7 dev build? If you want
to, I am more than willingly to work with you on this issue - if you
are running with a very recent AspectJ dev build and were able to
share dumps with me, I'll sort it out. Either email them to me or
zip/attach them to that bug report. yourkit is my preferred format,
but I can deal with pretty much anything. It would be interesting to
know if you are using a lot of ITDs, or simply advice? Since that
makes a difference on what gets held onto in a World.

> Do you think maybe the placement of the aop.xml, and/or the placement of
> aspectjweaver.jar may be the cause?

It could be the aop.xml merges causing you a headache, or it could
simply be the inability to say "I DONT WANT A DAMN WEAVER FOR THOSE
JSP CLASSLOADERS" :) An ability to filter which classloaders you want
a weaver for has been talked about before but there is currently no
mechanism. Do you believe you want to weave the result of JSP
compilation? I think there can be a ton of jsp classloaders in a
system, coming and going regularly. However, although a lot of memory
may be getting used, I don't understand why you are eventually running
out since care has been taken that once loaders go then weavers
attached to them also vanish. AspectJ shouldn't really be able to
cause PermGen issues by itself as it doesn't create and manage
classloaders itself, however *if* there is a bug and it is anchoring a
classloader that the system has already discarded, that could lead to
a permgen problem. In your heap dump, take a look for classloader
instances and whether any are being hard referenced through AspectJ.

> I feel like I've tried everything, so today I was converting all our modules
> to compile time weaving. Which impacts our development process and increases
> build-time and what not. But it works, and just loads the strictly necessary
> woven classes.

Latest aspectj has really improved some build times due to improved
matching algorithms. I heard AJDT build time was down from 55 seconds
to 38 seconds - both of which are low, but that saving should scale up
to any size system that is doing a decent amount of weaving.

> I also feel like I'm kind of hi-jacking this thread. Whoopsie.

No problem - we can continue this discussion on the mailing list, in
bugzilla or on email. up to you :)

cheers,
Andy
_______________________________________________
aspectj-users mailing list
aspectj-users@...
https://dev.eclipse.org/mailman/listinfo/aspectj-users

From forum: AspectJ - users

Re: Generated AjcClosure classes

2009-12-02T10:43:56Z

Hi Andy,

You are correct a key based just on the class bytecode is whole-fully
insufficient at least in the enterprise space because of classloaders
each of which can have different aspect
dependencies/libraries/configurations. JXInsight's enhanced AspectJ
weaver uses cache based on composite-key digests generated for
classloaders & classes that factors in such additional context
information. We also enhanced the load-time weaver with other
capabilities including class filtering, class differencing, diagnostics,
profiling,.... We have had this capability for more than 1 1/2 years.

Kind regards,

William

_______________________________________________
aspectj-users mailing list
aspectj-users@...
https://dev.eclipse.org/mailman/listinfo/aspectj-users

From forum: AspectJ - users

Re: Generated AjcClosure classes

2009-12-02T10:24:45Z

Hello,
On Dec 2, 2009, at 7:10 PM, Andy Clement wrote:

> Hey,
>
>> Great to hear this. Or not :) because I'm currently writing a paper about these things.
>> As a cache key I use a hash of the bytecode of the unaltered class. After I compute the hash, I weave aspects to the class and save the weaved class into the cache.
>> On subsequent program executions, I recompute the hash and retrieve the weaved version. When the list of aspects I instrument classes with changes, I invalidate the cache.
>> Thus, after changing the list of aspects, on subsequent runs, a new cache is rebuilt.
>
> Ok, let me throw something out there and you can tell me if you have
> considered this case, as it seems the big problem :) The hash of
> aspects and the class to be woven is not actually sufficient. Suppose
> I have this:
>
> aspect X {
> before(): execution(* Foo.*(..)) {}
> }
>
> class A extends B {
> public void m() {}
> }
>
> class B { }
>
> class Foo {
> public void m() {}
> }
>
> on first building/weaving that system, type A will not be woven. You
> will cache it according to hash#A and {X}
>
> Suppose I then change B:
>
> class B extends Foo {
> }
>
> Now you reload the system. A hasn't changed, neither has X, but A
> would now be woven because B changed - so if you use the cached entry,
> you will get the wrong result.
>
> I am thinking that hashing of the bytecode for 'A' isn't sufficient
> for the key, and perhaps it is more a hash of A 'plus dependencies
> that affect decisions made during weaving'. That latter information
> is something the weaver can know, and if included in the cachekey in
> some way, we can know that a change to B also means the cache value
> for A is out of date. Do you have another solution to this problem?
> This is why I was thinking about AspectJ doing its own caching,
> because it can know all these things.

Thanks for pointing this out. That is a problem. Currently, I was not thinking of systems that can change their code. Having this mentioned, I believe there is a non-aspect, albeit more inefficient way: when a class is loaded, Java will also load its superclass, interfaces, etc. Now, if those changed, I think it's safe to invalidate the current class as well and have it (re)weaved. Even if these super classes are already loaded, my analysis looks at all the classes the current class interacts with and I can manage to find that they changed as well. However, this solution incurs the overhead of reweaving classes that do not have to be modified.

>
>> One thing I'm considering is having caches for each sequence of applied aspects so as to not start from scratch if there is a common sub sequence between what I already cached and the new list of aspects.
>
> Yes, that is common with a profiling aspect where it is off, then you
> turn it on, then you turn it off again.
>
>>> There currently isn't a way for you to get at them I don't think - but
>>> there have been other requests to access them, or at least be made
>>> aware of them. This wasn't for a caching purpose but merely to avoid
>>> clashes in the case where an attempt is made to define the same class
>>> twice (https://bugs.eclipse.org/bugs/show_bug.cgi?id=287426).
>> So what happens with the $AjcClosure classes? Isn't there a way I can get their bytecode? WeavingAdaptor has a method called "accept" that sounds to do just that. Also, the WeavingAdaptor constructor takes in a "GeneratedClassHandler". Is there a way I can get a hold of that handler from within "Aj"?
>
> If you override functionality at a lower level, yes you can be plugged
> into the process (GeneratedClassHandler), but I thought you were
> running ltw as a standalone agent and then plugging your agent in
> separately - are you not doing that? Are you having your agent work
> with the LTW agent?

I have an agent in which I use Aj as a secondary agent. This architecture gives the option of easily implementing the cache verification without having to modify Aj.
>
> As I say, raise an enhancement request to discuss this.
How do I do that?

Cheers,
Silviu
>
> Andy
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@...
> https://dev.eclipse.org/mailman/listinfo/aspectj-users

_______________________________________________
aspectj-users mailing list
aspectj-users@...
https://dev.eclipse.org/mailman/listinfo/aspectj-users

From forum: AspectJ - users

Re: Generated AjcClosure classes

2009-12-02T10:18:10Z

Hi Silviu,
the accept method gives you classes generated by AspectJ, I don't use it
from an agent but from a classloader, and I can see closures being
pushed using that method.

I don't know if it is accessible from an agent however.

Simone

Andrica Silviu wrote:

> Hi,
>
> On Dec 2, 2009, at 6:11 PM, Andy Clement wrote:
>
>
>> Hi Silviu,
>>
>>
>>> I am using Aj to perform runtime weaving. Afterwards, I'm saving the weaved
>>> class into a cache so as to avoid the instrumentation on subsequent runs.
>>>
>> You know, I'm on the verge of creating such a thing in AspectJ
>> itself... I would be interested to here about your approach and how
>> you know when to invalidate the cache, and what are you using as the
>> cache key (some combination of the class itself hashed or something,
>> plus the combination of aspects defined at the time, hashed or
>> something?)
>>
> Great to hear this. Or not :) because I'm currently writing a paper about these things.
> As a cache key I use a hash of the bytecode of the unaltered class. After I compute the hash, I weave aspects to the class and save the weaved class into the cache.
> On subsequent program executions, I recompute the hash and retrieve the weaved version. When the list of aspects I instrument classes with changes, I invalidate the cache.
> Thus, after changing the list of aspects, on subsequent runs, a new cache is rebuilt. One thing I'm considering is having caches for each sequence of applied aspects so as to not start from scratch if there is a common sub sequence between what I already cached and the new list of aspects.
>
>
>
>> If AspectJ did this itself then the only user configuration would be a
>> place to keep these woven classes so that they can be retrieved later.
>> Do you have any specific requirements for the cache in your scenario?
>> (or does anyone else reading this have requirements on a cache like
>> this?)
>>
> Well, I would like to be able to retrieve them. Nothing more. A predefined place would be best.
>
>>> Now, my problem is that I use around advices that create additional
>>> Class$AjcClosure.
>>> Is there any way I can get handle of those classes? I must mention I am
>>> using a java agent that would normally be called whenever a new class is
>>> loaded, but it appears that the Closure classes somehow escape this.
>>>
>> There currently isn't a way for you to get at them I don't think - but
>> there have been other requests to access them, or at least be made
>> aware of them. This wasn't for a caching purpose but merely to avoid
>> clashes in the case where an attempt is made to define the same class
>> twice (https://bugs.eclipse.org/bugs/show_bug.cgi?id=287426).
>>
> So what happens with the $AjcClosure classes? Isn't there a way I can get their bytecode? WeavingAdaptor has a method called "accept" that sounds to do just that. Also, the WeavingAdaptor constructor takes in a "GeneratedClassHandler". Is there a way I can get a hold of that handler from within "Aj"?
>
> Thanks a lot!
>
> Silviu
>
>> Raise an enhancement request and I'll see what I can do.
>>
>> Andy
>> _______________________________________________
>> aspectj-users mailing list
>> aspectj-users@...
>> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>>
>
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@...
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>

From forum: AspectJ - users

Re: Generated AjcClosure classes

2009-12-02T10:10:35Z

Hey,

> Great to hear this. Or not :) because I'm currently writing a paper about these things.
> As a cache key I use a hash of the bytecode of the unaltered class. After I compute the hash, I weave aspects to the class and save the weaved class into the cache.
> On subsequent program executions, I recompute the hash and retrieve the weaved version. When the list of aspects I instrument classes with changes, I invalidate the cache.
> Thus, after changing the list of aspects, on subsequent runs, a new cache is rebuilt.

Ok, let me throw something out there and you can tell me if you have
considered this case, as it seems the big problem :) The hash of
aspects and the class to be woven is not actually sufficient. Suppose
I have this:

aspect X {
before(): execution(* Foo.*(..)) {}
}

class A extends B {
public void m() {}
}

class B { }

class Foo {
public void m() {}
}

on first building/weaving that system, type A will not be woven. You
will cache it according to hash#A and {X}

Suppose I then change B:

class B extends Foo {
}

Now you reload the system. A hasn't changed, neither has X, but A
would now be woven because B changed - so if you use the cached entry,
you will get the wrong result.

I am thinking that hashing of the bytecode for 'A' isn't sufficient
for the key, and perhaps it is more a hash of A 'plus dependencies
that affect decisions made during weaving'. That latter information
is something the weaver can know, and if included in the cachekey in
some way, we can know that a change to B also means the cache value
for A is out of date. Do you have another solution to this problem?
This is why I was thinking about AspectJ doing its own caching,
because it can know all these things.

> One thing I'm considering is having caches for each sequence of applied aspects so as to not start from scratch if there is a common sub sequence between what I already cached and the new list of aspects.

Yes, that is common with a profiling aspect where it is off, then you
turn it on, then you turn it off again.

>> There currently isn't a way for you to get at them I don't think - but
>> there have been other requests to access them, or at least be made
>> aware of them. This wasn't for a caching purpose but merely to avoid
>> clashes in the case where an attempt is made to define the same class
>> twice (https://bugs.eclipse.org/bugs/show_bug.cgi?id=287426).
> So what happens with the $AjcClosure classes? Isn't there a way I can get their bytecode? WeavingAdaptor has a method called "accept" that sounds to do just that. Also, the WeavingAdaptor constructor takes in a "GeneratedClassHandler". Is there a way I can get a hold of that handler from within "Aj"?

If you override functionality at a lower level, yes you can be plugged
into the process (GeneratedClassHandler), but I thought you were
running ltw as a standalone agent and then plugging your agent in
separately - are you not doing that? Are you having your agent work
with the LTW agent?

As I say, raise an enhancement request to discuss this.

Andy
_______________________________________________
aspectj-users mailing list
aspectj-users@...
https://dev.eclipse.org/mailman/listinfo/aspectj-users

From forum: AspectJ - users

Re: Memory consumption problems

2009-12-02T10:03:45Z

Hey Andy

Thanks for the quick reply.
We're seeing classes being loaded into the World that shouldn't.
I've been toying around with all sorts of regexp patterns, but nothing seemed to work.

We're running on a SunApp, and we include the aspectJWeaver.jar as a JVM argument, so as to have the agent for LTW. But what I think is happening, is that because we include it as a JVM argument, the adaptor (I think?) is loading _all_ classes loaded by the classloader in which AspectJWeaver.jar is loaded into, get loaded.
And since our aop.xml file with inclusions and exclusions is only in a child classloader (en EJB or Web), the filtering isn't going on.
When we look at the GC graph, it keeps adding and removing about 600mb of memory every minute or so.
And eventually leads to FullGC's and PermGen crash.
Analyzing the heapdumps so far has also pointed out a lot of AspectJ classes taking up a LOT of memory.
There are even BcelObjectTypes referring to compiled jsp's.
My theory is the map just keeps growing along with how many classes are loaded, and then the memory just isn't enough for loading in everything and crashes.

I have been suspecting aop.xml merging for this behaviour, but sort of ruled it out by getting rid of aop.xml in spring-agents.jar (which is found in the web-inf/lib of one of our modules deployed on the appserver, along with a sub-module jar that contains _our_ aop.xml with the correct inclusions and exclusions).

Documentation I was able to dig up anywhere on the internet was helpful, but I still feel like a total idiot about AspectJ.

I had found your blog post about the performance gain in 1.6.7 and was hopeful, but it didn't solve our problem (loading classes that should be excluded).

Do you think maybe the placement of the aop.xml, and/or the placement of aspectjweaver.jar may be the cause?
I tried adding an aop.xml with restrictions in the actual aspectJWeaver.jar that is included as a jvm argument too, but that didn't seem to work either.

I feel like I've tried everything, so today I was converting all our modules to compile time weaving. Which impacts our development process and increases build-time and what not. But it works, and just loads the strictly necessary woven classes.

I also feel like I'm kind of hi-jacking this thread. Whoopsie.

Andy Clement wrote:

Hi Tim,

Yes, the inclusions/exclusions define what gets pulled into the world
map for weaving, but they (and related weaver state for them) do still
consume a bunch of space. Any types pulled in during analysis of the
types for weaving is temporarily in the world but discarded later (or
rather orphaned later, for GC). Things are improved in AspectJ 1.6.7.
In 1.6.7, after a weave we more aggressively chuck away (orphan)
types that were not affected by ITDs. Basically trying to discard
anything which can easily/cheaply be discovered again later. If the
world is still too large then having a hook so we can be told we are
no longer needed (a shutdown type call) may be the 'final solution'.

More details on the strategy that is now turned on by default are in
this article:
http://andrewclement.blogspot.com/2009/04/aspectj-load-time-weaving-and-memory.html
In the article it is called type demotion and had to be switched on
prior to 1.6.7, but in 1.6.7 it is the default behaviour.

cheers,
Andy

2009/12/2 Tim Schraepen <sch3lp@gmail.com>:
>
> Why don't you just use the inclusion and exclusion rules in the aop.xml files
> to decide which classes actually get loaded into the World map?
>
>
> Andy Clement wrote:
>>
>> Given that doing the right thing with freeing memory is non trivial, I was
>> thinking just now about an interim measure. A user callable API where you
>> could indicate to the AspectJ infrastructure that you *knew* the
>> classloader
>> had finished loading everything you wanted it to. Upon making the API
>> call
>> we would immediately discard the whole weaver *but* keep a note of the
>> classloader so that any future attempts to load classes that would have
>> been
>> woven will receive suitable warning/error messages. I'll take any
>> comments
>> anyone has on doing something like that... I'm not sure how easy it is for
>> you to determine when you know everything has been loaded..
>>
>> Cheers
>>
>
> --
> View this message in context: http://old.nabble.com/Memory-consumption-problems-tp18649090p26607167.html
> Sent from the AspectJ - users mailing list archive at Nabble.com.
>
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>
_______________________________________________
aspectj-users mailing list
aspectj-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/aspectj-users

From forum: AspectJ - users

Re: Generated AjcClosure classes

2009-12-02T09:48:29Z

Hi,

On Dec 2, 2009, at 6:11 PM, Andy Clement wrote:

> Hi Silviu,
>
>> I am using Aj to perform runtime weaving. Afterwards, I'm saving the weaved
>> class into a cache so as to avoid the instrumentation on subsequent runs.
>
> You know, I'm on the verge of creating such a thing in AspectJ
> itself... I would be interested to here about your approach and how
> you know when to invalidate the cache, and what are you using as the
> cache key (some combination of the class itself hashed or something,
> plus the combination of aspects defined at the time, hashed or
> something?)

Great to hear this. Or not :) because I'm currently writing a paper about these things.
As a cache key I use a hash of the bytecode of the unaltered class. After I compute the hash, I weave aspects to the class and save the weaved class into the cache.
On subsequent program executions, I recompute the hash and retrieve the weaved version. When the list of aspects I instrument classes with changes, I invalidate the cache.
Thus, after changing the list of aspects, on subsequent runs, a new cache is rebuilt. One thing I'm considering is having caches for each sequence of applied aspects so as to not start from scratch if there is a common sub sequence between what I already cached and the new list of aspects.

>
> If AspectJ did this itself then the only user configuration would be a
> place to keep these woven classes so that they can be retrieved later.
> Do you have any specific requirements for the cache in your scenario?
> (or does anyone else reading this have requirements on a cache like
> this?)
Well, I would like to be able to retrieve them. Nothing more. A predefined place would be best.

>
>> Now, my problem is that I use around advices that create additional
>> Class$AjcClosure.
>> Is there any way I can get handle of those classes? I must mention I am
>> using a java agent that would normally be called whenever a new class is
>> loaded, but it appears that the Closure classes somehow escape this.
>
> There currently isn't a way for you to get at them I don't think - but
> there have been other requests to access them, or at least be made
> aware of them. This wasn't for a caching purpose but merely to avoid
> clashes in the case where an attempt is made to define the same class
> twice (https://bugs.eclipse.org/bugs/show_bug.cgi?id=287426).

So what happens with the $AjcClosure classes? Isn't there a way I can get their bytecode? WeavingAdaptor has a method called "accept" that sounds to do just that. Also, the WeavingAdaptor constructor takes in a "GeneratedClassHandler". Is there a way I can get a hold of that handler from within "Aj"?

Thanks a lot!

Silviu
>
> Raise an enhancement request and I'll see what I can do.
>
> Andy
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@...
> https://dev.eclipse.org/mailman/listinfo/aspectj-users

_______________________________________________
aspectj-users mailing list
aspectj-users@...
https://dev.eclipse.org/mailman/listinfo/aspectj-users

From forum: AspectJ - users

Re: Memory consumption problems

2009-12-02T09:43:45Z

Hi Tim,

Yes, the inclusions/exclusions define what gets pulled into the world
map for weaving, but they (and related weaver state for them) do still
consume a bunch of space. Any types pulled in during analysis of the
types for weaving is temporarily in the world but discarded later (or
rather orphaned later, for GC). Things are improved in AspectJ 1.6.7.
In 1.6.7, after a weave we more aggressively chuck away (orphan)
types that were not affected by ITDs. Basically trying to discard
anything which can easily/cheaply be discovered again later. If the
world is still too large then having a hook so we can be told we are
no longer needed (a shutdown type call) may be the 'final solution'.

More details on the strategy that is now turned on by default are in
this article:
http://andrewclement.blogspot.com/2009/04/aspectj-load-time-weaving-and-memory.html
In the article it is called type demotion and had to be switched on
prior to 1.6.7, but in 1.6.7 it is the default behaviour.

cheers,
Andy

2009/12/2 Tim Schraepen <sch3lp@...>:

>
> Why don't you just use the inclusion and exclusion rules in the aop.xml files
> to decide which classes actually get loaded into the World map?
>
>
> Andy Clement wrote:
>>
>> Given that doing the right thing with freeing memory is non trivial, I was
>> thinking just now about an interim measure. A user callable API where you
>> could indicate to the AspectJ infrastructure that you *knew* the
>> classloader
>> had finished loading everything you wanted it to. Upon making the API
>> call
>> we would immediately discard the whole weaver *but* keep a note of the
>> classloader so that any future attempts to load classes that would have
>> been
>> woven will receive suitable warning/error messages. I'll take any
>> comments
>> anyone has on doing something like that... I'm not sure how easy it is for
>> you to determine when you know everything has been loaded..
>>
>> Cheers
>>
>
> --
> View this message in context: http://old.nabble.com/Memory-consumption-problems-tp18649090p26607167.html
> Sent from the AspectJ - users mailing list archive at Nabble.com.
>
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@...
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>

_______________________________________________
aspectj-users mailing list
aspectj-users@...
https://dev.eclipse.org/mailman/listinfo/aspectj-users

From forum: AspectJ - users

Re: Generated AjcClosure classes

2009-12-02T09:11:49Z

Hi Silviu,

> I am using Aj to perform runtime weaving. Afterwards, I'm saving the weaved
> class into a cache so as to avoid the instrumentation on subsequent runs.

You know, I'm on the verge of creating such a thing in AspectJ
itself... I would be interested to here about your approach and how
you know when to invalidate the cache, and what are you using as the
cache key (some combination of the class itself hashed or something,
plus the combination of aspects defined at the time, hashed or
something?)

If AspectJ did this itself then the only user configuration would be a
place to keep these woven classes so that they can be retrieved later.
Do you have any specific requirements for the cache in your scenario?
(or does anyone else reading this have requirements on a cache like
this?)

> Now, my problem is that I use around advices that create additional
> Class$AjcClosure.
> Is there any way I can get handle of those classes? I must mention I am
> using a java agent that would normally be called whenever a new class is
> loaded, but it appears that the Closure classes somehow escape this.

There currently isn't a way for you to get at them I don't think - but
there have been other requests to access them, or at least be made
aware of them. This wasn't for a caching purpose but merely to avoid
clashes in the case where an attempt is made to define the same class
twice (https://bugs.eclipse.org/bugs/show_bug.cgi?id=287426).

Raise an enhancement request and I'll see what I can do.

Andy
_______________________________________________
aspectj-users mailing list
aspectj-users@...
https://dev.eclipse.org/mailman/listinfo/aspectj-users

From forum: AspectJ - users

Generated AjcClosure classes

2009-12-02T04:10:54Z

Hello,

I am using Aj to perform runtime weaving. Afterwards, I'm saving the weaved class into a cache so as to avoid the instrumentation on subsequent runs.

Now, my problem is that I use around advices that create additional Class$AjcClosure.

Is there any way I can get handle of those classes? I must mention I am using a java agent that would normally be called whenever a new class is loaded, but it appears that the Closure classes somehow escape this.

Thanks a lot,

Silviu

_______________________________________________
aspectj-users mailing list
aspectj-users@...
https://dev.eclipse.org/mailman/listinfo/aspectj-users

From forum: AspectJ - users

Re: Memory consumption problems

2009-12-02T03:07:40Z

Why don't you just use the inclusion and exclusion rules in the aop.xml files to decide which classes actually get loaded into the World map?

Andy Clement wrote:

Given that doing the right thing with freeing memory is non trivial, I was
thinking just now about an interim measure. A user callable API where you
could indicate to the AspectJ infrastructure that you *knew* the classloader
had finished loading everything you wanted it to. Upon making the API call
we would immediately discard the whole weaver *but* keep a note of the
classloader so that any future attempts to load classes that would have been
woven will receive suitable warning/error messages. I'll take any comments
anyone has on doing something like that... I'm not sure how easy it is for
you to determine when you know everything has been loaded..

Cheers

From forum: AspectJ - users

Re: Performance Issues when exposing context from Annotations

2009-11-30T13:09:39Z

Both changes are now in (bug fix and new syntax support). And
although annotation binding is now fast, annotation value binding (for
strings) is even faster in this scenario.

A simple benchmark, distilled from the original. CaseThree below is
the new syntax for directly binding annotation value strings
---
import org.aspectj.lang.*;
import org.aspectj.lang.reflect.*;
import java.lang.annotation.*;

@Retention(RetentionPolicy.RUNTIME)
@interface Marker {
String message();
}

public class Perf {

public static void main(String []argv) {
run(true);
run(false);
}

public static void run(boolean warmup) {
long stime = System.currentTimeMillis();
for (int i=0;i<1000000;i++) {
runOne();
}
long etime = System.currentTimeMillis();

long manual = (etime-stime);
stime = System.currentTimeMillis();
for (int i=0;i<1000000;i++) {
runTwo();
}
etime = System.currentTimeMillis();
long woven = (etime-stime);

stime = System.currentTimeMillis();
for (int i=0;i<1000000;i++) {
runThree();
}
etime = System.currentTimeMillis();
long optimal = (etime-stime);

if (!warmup) {
System.out.println("Manually fetching annotation with
getAnnotation(): "+manual+"ms");
System.out.println("Binding annotation with @annotation(Marker):
"+woven+"ms");
System.out.println("Binding annotation value with
@annotation(Marker(message)): "+optimal+"ms");
}
if (woven>manual) {
throw new RuntimeException("woven = "+woven+" manual = "+manual);
}
if (optimal>woven) {
throw new RuntimeException("optimal = "+optimal+" woven = "+woven);
}
}

@Marker(message="string")
public static void runOne() {
}

@Marker(message="string")
public static void runTwo() {
}

@Marker(message="string")
public static void runThree() {
}
}

aspect X {
public static int a,b,c;

// CaseOne: annotation fetching is done in the advice:
pointcut adviceRetrievesAnnotation(): execution(@Marker * runOne(..));
before(): adviceRetrievesAnnotation() {
Marker marker = (Marker) ((MethodSignature)
thisJoinPointStaticPart.getSignature()).getMethod().getAnnotation(Marker.class);
String s = marker.message();
a+=s.length();
}

// CaseTwo: annotation binding is done in the pointcut, advice
retrieves message
pointcut pointcutBindsAnnotation(Marker l): execution(@Marker *
runTwo(..)) && @annotation(l);
before(Marker l): pointcutBindsAnnotation(l) {
String s = l.message();
b+=s.length();
}

// CaseThree: annotation binding directly targets the message value
in the annotation
pointcut pointcutBindsAnnotationValue(String msg):
execution(@Marker * runThree(..)) && @annotation(Marker(msg));
before(String s): pointcutBindsAnnotationValue(s) {
c+=s.length();
}
}
---
Running it:
Manually fetching annotation with getAnnotation(): 645ms
Binding annotation with @annotation(Marker): 445ms
Binding annotation value with @annotation(Marker(message)): 3ms

I must say I've never seen a logging system that specifies the message
to log in the annotation, since normally the method signature is used
as an indication of where the system currently is. There is nothing
wrong with doing that but it goes a little way to explain the missing
optimization as it has never come up before. The logging aspects I've
seen before merely used the annotation as a marker, sometimes
expressing trace levels in it:

@Trace(TraveLevel.DEBUG)

and that kind of case which uses enums was optimized for (for matching
and binding).

If you come up with other scenarios, feel free to raise bugs for them!

cheers,
Andy

2009/11/30 Andy Clement <andrew.clement@...>:

> Yes, that is rather sub-optimal isn't it :) I'll look at the bug in a
> bit. Irrespective of that bug, the most absolute optimal way to
> express these pointcuts would probably be this:
>
> public pointcut loggedMethod() : execution(@Log * *(..));
> public pointcut log(String logMessage): loggedMethod() &&
> @annotation(Log(logMessage));
> public pointcut log2(): loggedMethod() && !cflowbelow(loggedMethod());
>
> In the middle one you can see I am binding the string property of the
> annotation directly.
>
> *unfortunately* that binding form isn't supported today (for strings)
> - it is only allowed for annotation values that are enums (see
> http://andrewclement.blogspot.com/2009/02/aspectj-optimized-annotation-value.html
> ). I might try to add support for strings whilst looking at the other
> issue.
>
> Andy
>
>
> 2009/11/30 Simone Gianni <simoneg@...>:
>> Hi Oliver,
>> yes, you are writing to the right mailing list.
>>
>> 3 seconds against 49 is quite shocking, but I can confirm getting 4 seconds
>> against 22 on my machine, which is wrong anyway. I'm using AspectJ 1.6.6,
>> compile time weaving, inside Eclipse with AJDT.
>>
>> I also tried rewriting your pointcuts a bit :
>>
>> public pointcut loggedMethod() : execution(@Log * *(..));
>> public pointcut log(Log log): loggedMethod() && @annotation(log); public
>> pointcut log2(): loggedMethod() && !cflowbelow(loggedMethod());
>>
>> this makes log and log2 two completely different pointcut "hierarchies",
>> making it easier to test them out one by one.
>>
>> Also, cflowbelow(log(Log)) could cause a second context extraction (very
>> useful for the wormhole pattern), that could make things go slower.
>>
>> However, it did not change the results, still getting 3/4 seconds against
>> 22/23.
>>
>> I removed the cflowbelow part completely, just to test only the context
>> extraction part :
>>
>> public pointcut loggedMethod() : execution(@Log * *(..));
>> public pointcut log(Log log): loggedMethod() && @annotation(log);
>>
>> Dynamic annotation :
>>
>> before(): loggedMethod() {
>> Log log = (Log) ((MethodSignature)
>> thisJoinPointStaticPart.getSignature()).getMethod().getAnnotation(Log.class);
>> log.message();
>> }
>> after() returning: loggedMethod() {
>> Log log = (Log) ((MethodSignature)
>> thisJoinPointStaticPart.getSignature()).getMethod().getAnnotation(Log.class);
>> log.message();
>> }
>>
>>
>> Annotation as parameter :
>>
>> before(Log log): log(log) {
>> log.message();
>> }
>> after(Log log) returning: log(log) {
>> log.message();
>> }
>>
>> And yes, the first one takes 2/3 seconds, the second one 22/23 seconds.
>>
>> Raising the number of cycles from 1 milion to 10 milion still results in 20
>> seconds agains 200 seconds, so a 1:10 ratio anyway.
>>
>> I checked that both matched correctly, obtained the same number of calls to
>> advice, checked that "log" was there and no other optimization was taking
>> place (also sent to output log.message()).
>>
>> Using javap on SampleProgram I can see that AspectJ weaves these
>> isntructions :
>>
>> 49: ldc #1; //class tests/SampleProgram
>> 51: ldc #92; //String calc
>> 53: iconst_0
>> 54: anewarray #74; //class java/lang/Class
>> 57: invokevirtual #78; //Method
>> java/lang/Class.getDeclaredMethod:(Ljava/lang/String;[Ljava/lang/Class;)Ljava/lang/reflect/Method;
>> 60: ldc #71; //class tests/Log
>> 62: invokevirtual #84; //Method
>> java/lang/reflect/Method.getAnnotation:(Ljava/lang/Class;)Ljava/lang/annotation/Annotation;
>> 65: checkcast #71; //class tests/Log
>> 68: invokevirtual #91; //Method
>> tests/Intercept.ajc$afterReturning$tests_Intercept$2$74fc38c9:(Ltests/Log;)V
>>
>> Which, in plain java, are :
>>
>> Log l =
>> SampleProgram.class.getDeclaredMethod("calc").getAnnotation(Log.class);
>>
>> If I change
>>
>> Log log = (Log) ((MethodSignature)
>> thisJoinPointStaticPart.getSignature()).getMethod().getAnnotation(Log.class);
>>
>> To
>>
>> Log log =
>> SampleProgram.class.getDeclaredMethod("calc").getAnnotation(Log.class);
>>
>> I obtain 23/24 seconds also with dynamic annotation lookup.
>>
>> So the problem is the suboptimal way used by AspectJ when weaving
>> @annotation(log).
>>
>> I raised the bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=296484 , and
>> given you credit for the discovery.
>>
>> Simone
>>
>> Oliver Hoff wrote:
>>>
>>> Hello,
>>>
>>> At first: If I am posting on the wrong list, I am sorry for that. I didnt
>>> got used to mailing lists so far. (yeah computer science young generation
>>> loves fancy Web2.0 communication tools)
>>>
>>> I recently started to play around with AspectJ and tried an aspect based
>>> generic logging example, where "log context configuration" (when and what
>>> should be logged) is specified within annotations. While I had no problems
>>> to get the example running, I have done some performance testing. While its
>>> definitly possible that I have messed with some "opimization guideline",
>>> maybe you will find the following test case interesting.
>>>
>>> Log Annotation:
>>> import java.lang.annotation.Retention;
>>> import java.lang.annotation.RetentionPolicy;
>>> @Retention(RetentionPolicy.RUNTIME)
>>> public @interface Log {
>>> String message() default "";
>>> }
>>>
>>> Test program:
>>> public class SampleProgram {
>>> public static void main(String[] args) {
>>> System.out.println(System.getProperties());
>>> run();
>>> }
>>> @Log(message="Outer")
>>> public static void run() {
>>> for(int i = 0; i < 1000000; i++) calc();
>>> } @Log(message="Inner")
>>> public static void calc() {
>>> for(int i = 0; i < 10; i++) Math.exp(i);
>>> }
>>> }
>>>
>>> Testaspect 1:
>>> import org.aspectj.lang.reflect.MethodSignature;
>>> public aspect Logging {
>>> public pointcut log(): execution(* *(..)) && @annotation(Log);
>>> public pointcut log2(): log() && !cflowbelow(log());
>>>
>>> before(): log() {
>>> Log log = (Log) ((MethodSignature)
>>> thisJoinPointStaticPart.getSignature()).getMethod().getAnnotation(Log.class);
>>> log.message();
>>> } before(): log2() {
>>> System.out.println("[" + System.currentTimeMillis() + "] [S " +
>>> thisJoinPointStaticPart.getSignature().getName() + "]");
>>> } after() returning: log() {
>>> Log log = (Log) ((MethodSignature)
>>> thisJoinPointStaticPart.getSignature()).getMethod().getAnnotation(Log.class);
>>> log.message();
>>> } after() returning: log2() {
>>> System.out.println("[" + System.currentTimeMillis() + "] [F " +
>>> thisJoinPointStaticPart.getSignature().getName() + "]");
>>> }
>>> }
>>>
>>> Testaspect 2:
>>> public aspect Logging2 {
>>> public pointcut log(Log log): execution(* *(..)) &&
>>> @annotation(log); public pointcut log2(): log(Log) &&
>>> !cflowbelow(log(Log));
>>>
>>> before(Log log): log(log) {
>>> log.message();
>>> } before(): log2() {
>>> System.out.println("[" + System.currentTimeMillis() + "] [S " +
>>> thisJoinPointStaticPart.getSignature().getName() + "]");
>>> } after(Log log) returning: log(log) {
>>> log.message();
>>> } after() returning: log2() {
>>> System.out.println("[" + System.currentTimeMillis() + "] [F " +
>>> thisJoinPointStaticPart.getSignature().getName() + "]");
>>> }
>>> }
>>>
>>> Testcase 1 output: (3 seconds execution time) (JIT on)
>>> {
>>> java.runtime.name=Java(TM) SE Runtime Environment,
>>> java.runtime.version=1.6.0_07-b06,
>>> java.vm.version=10.0-b23,
>>> java.vm.vendor=Sun Microsystems Inc.,
>>> java.vm.name=Java HotSpot(TM) Client VM,
>>> java.vm.specification.version=1.0,
>>> java.class.version=50.0,
>>> java.version=1.6.0_07,
>>> java.specification.version=1.6,
>>> sun.arch.data.model=32,
>>> ... and more ...
>>> }
>>> [1259542706359] [S run]
>>> [1259542709390] [F run]
>>>
>>> Testcase 2 output: (49 seconds execution time) (JIT on)
>>> { ... same as above ... }
>>> [1259542981187] [S run]
>>> [1259543029781] [F run]
>>>
>>> Testcase without aspects: round about 2 seconds
>>>
>>> As far as I have noticed the second example is the "right" way to access
>>> the information of an annotation, but it is more expensive than the first
>>> dynamic access.
>>>
>>> I hope that helps somehow and again if this is wrong place or information
>>> provided is useless, I am sorry for wasting your time.
>>>
>>> Mit freundlichen Grüßen (Sincerely)
>>> Oliver Hoff
>>> _______________________________________________
>>> aspectj-dev mailing list
>>> aspectj-dev@...
>>> https://dev.eclipse.org/mailman/listinfo/aspectj-dev
>>
>>
>> --
>> Simone Gianni CEO Semeru s.r.l. Apache Committer
>> http://www.simonegianni.it/
>>
>> _______________________________________________
>> aspectj-dev mailing list
>> aspectj-dev@...
>> https://dev.eclipse.org/mailman/listinfo/aspectj-dev
>>
>

_______________________________________________
aspectj-dev mailing list
aspectj-dev@...
https://dev.eclipse.org/mailman/listinfo/aspectj-dev

From forum: AspectJ - dev

Re: AspectJ in a netbeans RCP project

2009-11-30T12:31:28Z

Hi Dirk,

I don't know anything about NetBeans RCP, but if there is any
similarity to Eclipse RCP, then it is not simple to get aspects
working across modules. For Eclipse RCP (since it is built on top of
OSGi), we need to use Equinox Aspects so that the AspectJ weaver can
weave across OSGi bundles (ie- modules).

In other words, there is a difference between using aspects within a
single module and using them across modules. When not working across
modules, the standard aspectj compiler can be used, but when weaving
across modules, something more is required.

Wish I could be more help here...

--a

On Mon, Nov 30, 2009 at 11:47 AM, Dirk Walter <Dirk.Walter@...> wrote:

> Hi,
>
> I have been following the instructions at
> http://xentient.com/journal/2009/6/16/using-aspectj-with-netbeans.html
> to get AspectJ working with my Netbeans RCP based application.
>
> I only want to use one relatively simple aspect to test if stuff is
> happening inside the EDT, because I know much of the code isn't. Hence I
> am using the aspect code described at the bottom of this article,
> http://weblogs.java.net/blog/alexfromsun/archive/2006/02/debugging_swing.html to find all the areas where the gui is being accessed outside the EDT.
>
> However I seem to have problems using it across modules, does anyone
> have any advice on how to use AspectJ with the netbeans RCP so that the
> pointcuts apply to all modules? Since it is only being used for
> debugging I would ideally like it to be easy to add or remove.
>
> I am using the AspectJ pulgin by Ramos
> http://plugins.netbeans.org/PluginPortal/faces/PluginDetailPage.jsp?pluginid=4015 and netbeans 6.5 if that helps.
>
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@...
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>

_______________________________________________
aspectj-users mailing list
aspectj-users@...
https://dev.eclipse.org/mailman/listinfo/aspectj-users

From forum: AspectJ - users

AspectJ in a netbeans RCP project

2009-11-30T11:47:06Z

Hi,

I have been following the instructions at
http://xentient.com/journal/2009/6/16/using-aspectj-with-netbeans.html
to get AspectJ working with my Netbeans RCP based application.

I only want to use one relatively simple aspect to test if stuff is
happening inside the EDT, because I know much of the code isn't. Hence I
am using the aspect code described at the bottom of this article,
http://weblogs.java.net/blog/alexfromsun/archive/2006/02/debugging_swing.html to find all the areas where the gui is being accessed outside the EDT.

However I seem to have problems using it across modules, does anyone
have any advice on how to use AspectJ with the netbeans RCP so that the
pointcuts apply to all modules? Since it is only being used for
debugging I would ideally like it to be easy to add or remove.

I am using the AspectJ pulgin by Ramos
http://plugins.netbeans.org/PluginPortal/faces/PluginDetailPage.jsp?pluginid=4015 and netbeans 6.5 if that helps.

_______________________________________________
aspectj-users mailing list
aspectj-users@...
https://dev.eclipse.org/mailman/listinfo/aspectj-users

From forum: AspectJ - users

Re: AspectJ and code coverage?

2009-11-30T11:16:17Z

Would it be possible to provide a sample project with pom.xml on how to do it? Maybe this can be added to some wiki if there is one of aspectj or you can add it to the mavenuser wiki?

2009/11/30 Simone Gianni <simoneg@...>

Hi Wim,
I'm using Maven2 + AspectJ + Cobertura successfully, but there are a few caveats.

I'm currently weaving first and then instrumenting with cobertura. If I remember correctly, I'm cobertura-instrumenting the entire jar. I could do this cause in our setup coverage reports are executed in a separate step, when generating the project site. Since AspectJ inlines a few calls inside methods using "line 1" of the target class file, or the first line of the method, you'll see cobertura reporting a lot of hits on this lines, even if they does not contain any apparently useful code. This may confuse who is used to cobertura reports and not aware of AspectJ internals, but can be interpreted as useful informations cause you may understand how many instructions are executed because of AspectJ aspect lookup.

I also set up a "load time cobertura instrumentation", that goes in pair with load time weaving, but in that case if an entire class does not get loaded, cobertura knows nothing about it, which alters the global coverage measurements, so I dropped it.

If you have a specific error, I can try to investigate it.

Simone

Wim Deblauwe wrote:

Hi,

is there anybody who is using AspectJ with a code coverage tool. We are using Cobertura and Maven2, but that does not work when you start to add an aspect to your code and you need to use the ajc compiler. I just checked with Atlassian and Clover cannot seem to manage it according to them. Anybody knows a workaround? I don't want to have code coverage on the aspect, I just don't want to loose the coverage on my regular java classes.

regards,

Wim
------------------------------------------------------------------------

_______________________________________________
aspectj-users mailing list
aspectj-users@...
https://dev.eclipse.org/mailman/listinfo/aspectj-users

--
Simone Gianni CEO Semeru s.r.l. Apache Committer
http://www.simonegianni.it/

_______________________________________________
aspectj-users mailing list
aspectj-users@...
https://dev.eclipse.org/mailman/listinfo/aspectj-users

_______________________________________________
aspectj-users mailing list
aspectj-users@...
https://dev.eclipse.org/mailman/listinfo/aspectj-users

From forum: AspectJ - users

Re: Equinox Aspects LTW: capturing aspect instantiation

2009-11-30T11:06:42Z

Hi Martin,

I guess the one you mentioned is the problem (no idea how to check it though ;)). I've defined a "real" aspect in my aop.xml:

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE aspectj PUBLIC "-//AspectJ//DTD//EN" "http://www.eclipse.org/aspectj/dtd/aspectj.dtd">

<!-- SWT Thread Safety

<concrete-aspect name="it.uniba.di.cdg.jtalk.aspects.SWTThreadingAspect"

extends="it.uniba.di.cdg.penelope.ui.swt.AbstractSWTThreadingAspect">

</concrete-aspect>

-->

<concrete-aspect name="it.uniba.di.cdg.jtalk.aspects.AspectInjectionAspect"

extends="it.uniba.di.cdg.penelope.AbstractAspectInjectionAspect">

</concrete-aspect>

</aspects>

</aspectj>

The aspect is just:

package it.uniba.di.cdg.jtalk.aspects;

import org.aspectj.lang.annotation.Aspect;

import org.aspectj.lang.annotation.Pointcut;

import it.uniba.di.cdg.penelope.ui.swt.AbstractSWTThreadingAspect;

@Aspect

public class SWTThreadingAspect extends AbstractSWTThreadingAspect {

@Override

@Pointcut( "within( it.uniba.di.cdg.jtalk.ui..* )" )

public void scope() {}

}

In this way, SWTThreadingAspect's instantiation is correctly catched by the synthetic AspectInjectionAspect.

The good thing is that I can dependency inject aspects in this way; the bad one is that I must define "dummy" aspect classes (plus the aop.xml entry) in order to do in code what I may archieve just within the aop.xml file.

Cheers,

Mario

On Mon, Nov 30, 2009 at 11:55 AM, Martin Lippert <lippert@...> wrote:

Hi Mario,

I am not sure but I think this could be a general LTW problem. I assume the concrete aspects from aop.xml are not passed to the weaver for weaving before defined in the VM, correct?

Crossposting to aspectj-dev for discussing the implementation details of this setting...

Cheers,
-Martin

_______________________________________________
aspectj-users mailing list
aspectj-users@...
https://dev.eclipse.org/mailman/listinfo/aspectj-users

--
"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan

_______________________________________________
aspectj-users mailing list
aspectj-users@...
https://dev.eclipse.org/mailman/listinfo/aspectj-users

From forum: AspectJ - users

Re: Performance Issues when exposing context from Annotations

2009-11-30T09:22:14Z

Yes, that is rather sub-optimal isn't it :) I'll look at the bug in a
bit. Irrespective of that bug, the most absolute optimal way to
express these pointcuts would probably be this:

public pointcut loggedMethod() : execution(@Log * *(..));
public pointcut log(String logMessage): loggedMethod() &&
@annotation(Log(logMessage));
public pointcut log2(): loggedMethod() && !cflowbelow(loggedMethod());

In the middle one you can see I am binding the string property of the
annotation directly.

*unfortunately* that binding form isn't supported today (for strings)
- it is only allowed for annotation values that are enums (see
http://andrewclement.blogspot.com/2009/02/aspectj-optimized-annotation-value.html
). I might try to add support for strings whilst looking at the other
issue.

Andy

2009/11/30 Simone Gianni <simoneg@...>:

> Hi Oliver,
> yes, you are writing to the right mailing list.
>
> 3 seconds against 49 is quite shocking, but I can confirm getting 4 seconds
> against 22 on my machine, which is wrong anyway. I'm using AspectJ 1.6.6,
> compile time weaving, inside Eclipse with AJDT.
>
> I also tried rewriting your pointcuts a bit :
>
> public pointcut loggedMethod() : execution(@Log * *(..));
> public pointcut log(Log log): loggedMethod() && @annotation(log); public
> pointcut log2(): loggedMethod() && !cflowbelow(loggedMethod());
>
> this makes log and log2 two completely different pointcut "hierarchies",
> making it easier to test them out one by one.
>
> Also, cflowbelow(log(Log)) could cause a second context extraction (very
> useful for the wormhole pattern), that could make things go slower.
>
> However, it did not change the results, still getting 3/4 seconds against
> 22/23.
>
> I removed the cflowbelow part completely, just to test only the context
> extraction part :
>
> public pointcut loggedMethod() : execution(@Log * *(..));
> public pointcut log(Log log): loggedMethod() && @annotation(log);
>
> Dynamic annotation :
>
> before(): loggedMethod() {
> Log log = (Log) ((MethodSignature)
> thisJoinPointStaticPart.getSignature()).getMethod().getAnnotation(Log.class);
> log.message();
> }
> after() returning: loggedMethod() {
> Log log = (Log) ((MethodSignature)
> thisJoinPointStaticPart.getSignature()).getMethod().getAnnotation(Log.class);
> log.message();
> }
>
>
> Annotation as parameter :
>
> before(Log log): log(log) {
> log.message();
> }
> after(Log log) returning: log(log) {
> log.message();
> }
>
> And yes, the first one takes 2/3 seconds, the second one 22/23 seconds.
>
> Raising the number of cycles from 1 milion to 10 milion still results in 20
> seconds agains 200 seconds, so a 1:10 ratio anyway.
>
> I checked that both matched correctly, obtained the same number of calls to
> advice, checked that "log" was there and no other optimization was taking
> place (also sent to output log.message()).
>
> Using javap on SampleProgram I can see that AspectJ weaves these
> isntructions :
>
> 49: ldc #1; //class tests/SampleProgram
> 51: ldc #92; //String calc
> 53: iconst_0
> 54: anewarray #74; //class java/lang/Class
> 57: invokevirtual #78; //Method
> java/lang/Class.getDeclaredMethod:(Ljava/lang/String;[Ljava/lang/Class;)Ljava/lang/reflect/Method;
> 60: ldc #71; //class tests/Log
> 62: invokevirtual #84; //Method
> java/lang/reflect/Method.getAnnotation:(Ljava/lang/Class;)Ljava/lang/annotation/Annotation;
> 65: checkcast #71; //class tests/Log
> 68: invokevirtual #91; //Method
> tests/Intercept.ajc$afterReturning$tests_Intercept$2$74fc38c9:(Ltests/Log;)V
>
> Which, in plain java, are :
>
> Log l =
> SampleProgram.class.getDeclaredMethod("calc").getAnnotation(Log.class);
>
> If I change
>
> Log log = (Log) ((MethodSignature)
> thisJoinPointStaticPart.getSignature()).getMethod().getAnnotation(Log.class);
>
> To
>
> Log log =
> SampleProgram.class.getDeclaredMethod("calc").getAnnotation(Log.class);
>
> I obtain 23/24 seconds also with dynamic annotation lookup.
>
> So the problem is the suboptimal way used by AspectJ when weaving
> @annotation(log).
>
> I raised the bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=296484 , and
> given you credit for the discovery.
>
> Simone
>
> Oliver Hoff wrote:
>>
>> Hello,
>>
>> At first: If I am posting on the wrong list, I am sorry for that. I didnt
>> got used to mailing lists so far. (yeah computer science young generation
>> loves fancy Web2.0 communication tools)
>>
>> I recently started to play around with AspectJ and tried an aspect based
>> generic logging example, where "log context configuration" (when and what
>> should be logged) is specified within annotations. While I had no problems
>> to get the example running, I have done some performance testing. While its
>> definitly possible that I have messed with some "opimization guideline",
>> maybe you will find the following test case interesting.
>>
>> Log Annotation:
>> import java.lang.annotation.Retention;
>> import java.lang.annotation.RetentionPolicy;
>> @Retention(RetentionPolicy.RUNTIME)
>> public @interface Log {
>> String message() default "";
>> }
>>
>> Test program:
>> public class SampleProgram {
>> public static void main(String[] args) {
>> System.out.println(System.getProperties());
>> run();
>> }
>> @Log(message="Outer")
>> public static void run() {
>> for(int i = 0; i < 1000000; i++) calc();
>> } @Log(message="Inner")
>> public static void calc() {
>> for(int i = 0; i < 10; i++) Math.exp(i);
>> }
>> }
>>
>> Testaspect 1:
>> import org.aspectj.lang.reflect.MethodSignature;
>> public aspect Logging {
>> public pointcut log(): execution(* *(..)) && @annotation(Log);
>> public pointcut log2(): log() && !cflowbelow(log());
>>
>> before(): log() {
>> Log log = (Log) ((MethodSignature)
>> thisJoinPointStaticPart.getSignature()).getMethod().getAnnotation(Log.class);
>> log.message();
>> } before(): log2() {
>> System.out.println("[" + System.currentTimeMillis() + "] [S " +
>> thisJoinPointStaticPart.getSignature().getName() + "]");
>> } after() returning: log() {
>> Log log = (Log) ((MethodSignature)
>> thisJoinPointStaticPart.getSignature()).getMethod().getAnnotation(Log.class);
>> log.message();
>> } after() returning: log2() {
>> System.out.println("[" + System.currentTimeMillis() + "] [F " +
>> thisJoinPointStaticPart.getSignature().getName() + "]");
>> }
>> }
>>
>> Testaspect 2:
>> public aspect Logging2 {
>> public pointcut log(Log log): execution(* *(..)) &&
>> @annotation(log); public pointcut log2(): log(Log) &&
>> !cflowbelow(log(Log));
>>
>> before(Log log): log(log) {
>> log.message();
>> } before(): log2() {
>> System.out.println("[" + System.currentTimeMillis() + "] [S " +
>> thisJoinPointStaticPart.getSignature().getName() + "]");
>> } after(Log log) returning: log(log) {
>> log.message();
>> } after() returning: log2() {
>> System.out.println("[" + System.currentTimeMillis() + "] [F " +
>> thisJoinPointStaticPart.getSignature().getName() + "]");
>> }
>> }
>>
>> Testcase 1 output: (3 seconds execution time) (JIT on)
>> {
>> java.runtime.name=Java(TM) SE Runtime Environment,
>> java.runtime.version=1.6.0_07-b06,
>> java.vm.version=10.0-b23,
>> java.vm.vendor=Sun Microsystems Inc.,
>> java.vm.name=Java HotSpot(TM) Client VM,
>> java.vm.specification.version=1.0,
>> java.class.version=50.0,
>> java.version=1.6.0_07,
>> java.specification.version=1.6,
>> sun.arch.data.model=32,
>> ... and more ...
>> }
>> [1259542706359] [S run]
>> [1259542709390] [F run]
>>
>> Testcase 2 output: (49 seconds execution time) (JIT on)
>> { ... same as above ... }
>> [1259542981187] [S run]
>> [1259543029781] [F run]
>>
>> Testcase without aspects: round about 2 seconds
>>
>> As far as I have noticed the second example is the "right" way to access
>> the information of an annotation, but it is more expensive than the first
>> dynamic access.
>>
>> I hope that helps somehow and again if this is wrong place or information
>> provided is useless, I am sorry for wasting your time.
>>
>> Mit freundlichen Grüßen (Sincerely)
>> Oliver Hoff
>> _______________________________________________
>> aspectj-dev mailing list
>> aspectj-dev@...
>> https://dev.eclipse.org/mailman/listinfo/aspectj-dev
>
>
> --
> Simone Gianni CEO Semeru s.r.l. Apache Committer
> http://www.simonegianni.it/
>
> _______________________________________________
> aspectj-dev mailing list
> aspectj-dev@...
> https://dev.eclipse.org/mailman/listinfo/aspectj-dev
>

_______________________________________________
aspectj-dev mailing list
aspectj-dev@...
https://dev.eclipse.org/mailman/listinfo/aspectj-dev

From forum: AspectJ - dev

Re: AspectJ and code coverage?

2009-11-30T09:16:01Z

Hi Simone,

Regarding:

> Since AspectJ inlines a few calls inside methods using "line 1" of the target class file, or the first line of the method,
> you'll see cobertura reporting a lot of hits on this lines, even if they does not contain any apparently useful code.

Do you think there is something better we can do to produce nicer
reports? (I'd probably use synthetics, or fix up the lines to
something more appropriate, or get that SMAP thing going that we've
put off for so long)

Andy

2009/11/30 Simone Gianni <simoneg@...>:

> Hi Wim,
> I'm using Maven2 + AspectJ + Cobertura successfully, but there are a few
> caveats.
>
> I'm currently weaving first and then instrumenting with cobertura. If I
> remember correctly, I'm cobertura-instrumenting the entire jar. I could do
> this cause in our setup coverage reports are executed in a separate step,
> when generating the project site. Since AspectJ inlines a few calls inside
> methods using "line 1" of the target class file, or the first line of the
> method, you'll see cobertura reporting a lot of hits on this lines, even if
> they does not contain any apparently useful code. This may confuse who is
> used to cobertura reports and not aware of AspectJ internals, but can be
> interpreted as useful informations cause you may understand how many
> instructions are executed because of AspectJ aspect lookup.
>
> I also set up a "load time cobertura instrumentation", that goes in pair
> with load time weaving, but in that case if an entire class does not get
> loaded, cobertura knows nothing about it, which alters the global coverage
> measurements, so I dropped it.
>
> If you have a specific error, I can try to investigate it.
>
> Simone
>
>
>
> Wim Deblauwe wrote:
>>
>> Hi,
>>
>> is there anybody who is using AspectJ with a code coverage tool. We are
>> using Cobertura and Maven2, but that does not work when you start to add an
>> aspect to your code and you need to use the ajc compiler. I just checked
>> with Atlassian and Clover cannot seem to manage it according to them.
>> Anybody knows a workaround? I don't want to have code coverage on the
>> aspect, I just don't want to loose the coverage on my regular java classes.
>>
>> regards,
>>
>> Wim
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> aspectj-users mailing list
>> aspectj-users@...
>> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>>
>
>
> --
> Simone Gianni CEO Semeru s.r.l. Apache Committer
> http://www.simonegianni.it/
>
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@...
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>

_______________________________________________
aspectj-users mailing list
aspectj-users@...
https://dev.eclipse.org/mailman/listinfo/aspectj-users

From forum: AspectJ - users

Re: Performance Issues when exposing context from Annotations

2009-11-30T07:40:31Z

Hi Oliver,
yes, you are writing to the right mailing list.

3 seconds against 49 is quite shocking, but I can confirm getting 4
seconds against 22 on my machine, which is wrong anyway. I'm using
AspectJ 1.6.6, compile time weaving, inside Eclipse with AJDT.

I also tried rewriting your pointcuts a bit :

public pointcut loggedMethod() : execution(@Log * *(..));
public pointcut log(Log log): loggedMethod() && @annotation(log);
public pointcut log2(): loggedMethod() && !cflowbelow(loggedMethod());

this makes log and log2 two completely different pointcut "hierarchies",
making it easier to test them out one by one.

Also, cflowbelow(log(Log)) could cause a second context extraction (very
useful for the wormhole pattern), that could make things go slower.

However, it did not change the results, still getting 3/4 seconds
against 22/23.

I removed the cflowbelow part completely, just to test only the context
extraction part :

public pointcut loggedMethod() : execution(@Log * *(..));
public pointcut log(Log log): loggedMethod() && @annotation(log);

Dynamic annotation :

before(): loggedMethod() {
Log log = (Log) ((MethodSignature)
thisJoinPointStaticPart.getSignature()).getMethod().getAnnotation(Log.class);

log.message();
}
after() returning: loggedMethod() {
Log log = (Log) ((MethodSignature)
thisJoinPointStaticPart.getSignature()).getMethod().getAnnotation(Log.class);

log.message();
}

Annotation as parameter :

before(Log log): log(log) {
log.message();
}
after(Log log) returning: log(log) {
log.message();
}

And yes, the first one takes 2/3 seconds, the second one 22/23 seconds.

Raising the number of cycles from 1 milion to 10 milion still results in
20 seconds agains 200 seconds, so a 1:10 ratio anyway.

I checked that both matched correctly, obtained the same number of calls
to advice, checked that "log" was there and no other optimization was
taking place (also sent to output log.message()).

Using javap on SampleProgram I can see that AspectJ weaves these
isntructions :

49: ldc #1; //class tests/SampleProgram
51: ldc #92; //String calc
53: iconst_0
54: anewarray #74; //class java/lang/Class
57: invokevirtual #78; //Method
java/lang/Class.getDeclaredMethod:(Ljava/lang/String;[Ljava/lang/Class;)Ljava/lang/reflect/Method;
60: ldc #71; //class tests/Log
62: invokevirtual #84; //Method
java/lang/reflect/Method.getAnnotation:(Ljava/lang/Class;)Ljava/lang/annotation/Annotation;
65: checkcast #71; //class tests/Log
68: invokevirtual #91; //Method
tests/Intercept.ajc$afterReturning$tests_Intercept$2$74fc38c9:(Ltests/Log;)V

Which, in plain java, are :

Log l =
SampleProgram.class.getDeclaredMethod("calc").getAnnotation(Log.class);

If I change

Log log = (Log) ((MethodSignature)
thisJoinPointStaticPart.getSignature()).getMethod().getAnnotation(Log.class);

To

Log log =
SampleProgram.class.getDeclaredMethod("calc").getAnnotation(Log.class);

I obtain 23/24 seconds also with dynamic annotation lookup.

So the problem is the suboptimal way used by AspectJ when weaving
@annotation(log).

I raised the bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=296484 ,
and given you credit for the discovery.

Simone

Oliver Hoff wrote:

> Hello,
>
> At first: If I am posting on the wrong list, I am sorry for that. I
> didnt got used to mailing lists so far. (yeah computer science young
> generation loves fancy Web2.0 communication tools)
>
> I recently started to play around with AspectJ and tried an aspect
> based generic logging example, where "log context configuration" (when
> and what should be logged) is specified within annotations. While I
> had no problems to get the example running, I have done some
> performance testing. While its definitly possible that I have messed
> with some "opimization guideline", maybe you will find the following
> test case interesting.
>
> Log Annotation:
> import java.lang.annotation.Retention;
> import java.lang.annotation.RetentionPolicy;
> @Retention(RetentionPolicy.RUNTIME)
> public @interface Log {
> String message() default "";
> }
>
> Test program:
> public class SampleProgram {
> public static void main(String[] args) {
> System.out.println(System.getProperties());
> run();
> }
> @Log(message="Outer")
> public static void run() {
> for(int i = 0; i < 1000000; i++) calc();
> }
> @Log(message="Inner")
> public static void calc() {
> for(int i = 0; i < 10; i++) Math.exp(i);
> }
> }
>
> Testaspect 1:
> import org.aspectj.lang.reflect.MethodSignature;
> public aspect Logging {
>
> public pointcut log(): execution(* *(..)) && @annotation(Log);
> public pointcut log2(): log() && !cflowbelow(log());
>
> before(): log() {
> Log log = (Log) ((MethodSignature)
> thisJoinPointStaticPart.getSignature()).getMethod().getAnnotation(Log.class);
>
> log.message();
> }
> before(): log2() {
> System.out.println("[" + System.currentTimeMillis() + "] [S "
> + thisJoinPointStaticPart.getSignature().getName() + "]");
> }
> after() returning: log() {
> Log log = (Log) ((MethodSignature)
> thisJoinPointStaticPart.getSignature()).getMethod().getAnnotation(Log.class);
>
> log.message();
> }
> after() returning: log2() {
> System.out.println("[" + System.currentTimeMillis() + "] [F "
> + thisJoinPointStaticPart.getSignature().getName() + "]");
> }
> }
>
> Testaspect 2:
> public aspect Logging2 {
>
> public pointcut log(Log log): execution(* *(..)) &&
> @annotation(log);
> public pointcut log2(): log(Log) && !cflowbelow(log(Log));
>
> before(Log log): log(log) {
> log.message();
> }
> before(): log2() {
> System.out.println("[" + System.currentTimeMillis() + "] [S "
> + thisJoinPointStaticPart.getSignature().getName() + "]");
> }
> after(Log log) returning: log(log) {
> log.message();
> }
> after() returning: log2() {
> System.out.println("[" + System.currentTimeMillis() + "] [F "
> + thisJoinPointStaticPart.getSignature().getName() + "]");
> }
> }
>
> Testcase 1 output: (3 seconds execution time) (JIT on)
> {
> java.runtime.name=Java(TM) SE Runtime Environment,
> java.runtime.version=1.6.0_07-b06,
> java.vm.version=10.0-b23,
> java.vm.vendor=Sun Microsystems Inc.,
> java.vm.name=Java HotSpot(TM) Client VM,
> java.vm.specification.version=1.0,
> java.class.version=50.0,
> java.version=1.6.0_07,
> java.specification.version=1.6,
> sun.arch.data.model=32,
> ... and more ...
> }
> [1259542706359] [S run]
> [1259542709390] [F run]
>
> Testcase 2 output: (49 seconds execution time) (JIT on)
> { ... same as above ... }
> [1259542981187] [S run]
> [1259543029781] [F run]
>
> Testcase without aspects: round about 2 seconds
>
> As far as I have noticed the second example is the "right" way to
> access the information of an annotation, but it is more expensive
> than the first dynamic access.
>
> I hope that helps somehow and again if this is wrong place or
> information provided is useless, I am sorry for wasting your time.
>
> Mit freundlichen Grüßen (Sincerely)
> Oliver Hoff
> _______________________________________________
> aspectj-dev mailing list
> aspectj-dev@...
> https://dev.eclipse.org/mailman/listinfo/aspectj-dev

--
Simone Gianni CEO Semeru s.r.l. Apache Committer
http://www.simonegianni.it/

_______________________________________________
aspectj-dev mailing list
aspectj-dev@...
https://dev.eclipse.org/mailman/listinfo/aspectj-dev

From forum: AspectJ - dev