Hi Andy,
To capture more accurate result, I design the profiler process as follows,
(1)capture JVM heap states before serving any request, so there's no Aj will be initialized at this moment.
(2)make requests to my application repeatedly, so for each request, a new Aj will be created, and after fullfil the request, my application will release
the created ClassLoader and remove staled weavers, as the output below showed, different ExplicitlyInitializedClassLoaderWeavingAdaptor instance will be clean up.
(3)after around 20 request run, so we will have 20 ClassLoader and 20 Aj created, I made the second snapshot of heap state, and compare it with my previous capturing,
this will show me what objects still remained.
From the result, surprisingly in the second capturing, there's neither my Classloader instance nor any aspectj instance remained, so I did not understand why this happened.
What consume the memory? I ran the process several times, I got the same result, I hope you can have the answer.
Anfernee
[echo] ==== BEGIN repetitive execution ====
[echo] count=20,param=repeat.counter, parallel=false, threadCount=5, keepgoing=false, failonerror=true, name=repeat, result=repeat.result
[echo] ---- ITERATION 1 ----
[AJ] [WeaveClassLoaderImpl@995a79] info AspectJ Weaver Version 1.6.1 built on Thursday Jul 3, 2008 at 18:35:41 GMT
[AJ] [WeaveClassLoaderImpl@995a79] info register classloader com.ctc..ant.WeaveClassLoaderImpl@995a79
[AJ] [WeaveClassLoaderImpl@995a79] info using configuration file:/D:/works/weaver/antjunit-aspect.jar!/M
[AJ] [WeaveClassLoaderImpl@995a79] info register aspect com.ctc.aspects.TestAspect
[AJ] [2008-07-24 11:13:58] BEGIN tests.TestFoo.testOne
[AJ] [2008-07-24 11:13:58] SUCCESS tests.TestFoo.testOne
[AJ] [2008-07-24 11:13:58] BEGIN tests.TestFoo.testTimeout
[AJ] [2008-07-24 11:13:58] SUCCESS tests.TestFoo.testTimeout
[AJ] [2008-07-24 11:13:58] BEGIN tests.TestFoo.testTwo
[AJ] [2008-07-24 11:13:58] SUCCESS tests.TestFoo.testTwo
[AJ] Weaver adaptors before queue processing:
[AJ] org.aspectj.weaver.loadtime.Aj$AdaptorKey@162a137d = org.aspectj.weaver.loadtime.Aj$ExplicitlyInitializedClassLoaderWeavingAdaptor@a9509d
[AJ] Weaver adaptors after queue processing:
[AJ] org.aspectj.weaver.loadtime.Aj$AdaptorKey@162a137d = org.aspectj.weaver.loadtime.Aj$ExplicitlyInitializedClassLoaderWeavingAdaptor@a9509d
[AJ] Weaver adaptors before queue processing:
[AJ] org.aspectj.weaver.loadtime.Aj$AdaptorKey@162a137d = org.aspectj.weaver.loadtime.Aj$ExplicitlyInitializedClassLoaderWeavingAdaptor@a9509d
[AJ] Weaver adaptors after queue processing:
[AJ] org.aspectj.weaver.loadtime.Aj$AdaptorKey@162a137d = org.aspectj.weaver.loadtime.Aj$ExplicitlyInitializedClassLoaderWeavingAdaptor@a9509d
[stopwatch] [repeat: 1, time: 8.828 sec]
[echo] ---- ITERATION 2 ----
[AJ] [WeaveClassLoaderImpl@2d13c1] info AspectJ Weaver Version 1.6.1 built on Thursday Jul 3, 2008 at 18:35:41 GMT
[AJ] [WeaveClassLoaderImpl@2d13c1] info register classloader com.ctc..ant.WeaveClassLoaderImpl@2d13c1
[AJ] [WeaveClassLoaderImpl@2d13c1] info using configuration file:/D:/works/weaver/antjunit-aspect.jar!/M
[AJ] [WeaveClassLoaderImpl@2d13c1] info register aspect com.ctc.aspects.TestAspect
[AJ] [2008-07-24 11:14:07] BEGIN tests.TestFoo.testOne
[AJ] [2008-07-24 11:14:07] SUCCESS tests.TestFoo.testOne
[AJ] [2008-07-24 11:14:07] BEGIN tests.TestFoo.testTimeout
[AJ] [2008-07-24 11:14:07] SUCCESS tests.TestFoo.testTimeout
[AJ] [2008-07-24 11:14:07] BEGIN tests.TestFoo.testTwo
[AJ] [2008-07-24 11:14:07] SUCCESS tests.TestFoo.testTwo
[AJ] Weaver adaptors before queue processing:
[AJ] org.aspectj.weaver.loadtime.Aj$AdaptorKey@683dae5 = org.aspectj.weaver.loadtime.Aj$ExplicitlyInitializedClassLoaderWeavingAdaptor@205df9
[AJ] Weaver adaptors after queue processing:
[AJ] org.aspectj.weaver.loadtime.Aj$AdaptorKey@683dae5 = org.aspectj.weaver.loadtime.Aj$ExplicitlyInitializedClassLoaderWeavingAdaptor@205df9
[AJ] Weaver adaptors before queue processing:
[AJ] org.aspectj.weaver.loadtime.Aj$AdaptorKey@683dae5 = org.aspectj.weaver.loadtime.Aj$ExplicitlyInitializedClassLoaderWeavingAdaptor@205df9
[AJ] Weaver adaptors after queue processing:
[AJ] org.aspectj.weaver.loadtime.Aj$AdaptorKey@683dae5 = org.aspectj.weaver.loadtime.Aj$ExplicitlyInitializedClassLoaderWeavingAdaptor@205df9
[stopwatch] [repeat: 2, time: 9.375 sec]
[echo] ---- ITERATION 3 ----
[AJ] [WeaveClassLoaderImpl@1704ebb] info AspectJ Weaver Version 1.6.1 built on Thursday Jul 3, 2008 at 18:35:41 GMT
[AJ] [WeaveClassLoaderImpl@1704ebb] info register classloader com.ctc..ant.WeaveClassLoaderImpl@1704ebb
[AJ] [WeaveClassLoaderImpl@1704ebb] info using configuration file:/D:/works/weaver/antjunit-aspect.jar!/
[AJ] [WeaveClassLoaderImpl@1704ebb] info register aspect com.ctc.aspects.TestAspect
[AJ] [2008-07-24 11:14:16] BEGIN tests.TestFoo.testOne
[AJ] [2008-07-24 11:14:16] SUCCESS tests.TestFoo.testOne
[AJ] [2008-07-24 11:14:16] BEGIN tests.TestFoo.testTimeout
[AJ] [2008-07-24 11:14:16] SUCCESS tests.TestFoo.testTimeout
[AJ] [2008-07-24 11:14:16] BEGIN tests.TestFoo.testTwo
[AJ] [2008-07-24 11:14:16] SUCCESS tests.TestFoo.testTwo
[AJ] Weaver adaptors before queue processing:
[AJ] org.aspectj.weaver.loadtime.Aj$AdaptorKey@353b6107 = org.aspectj.weaver.loadtime.Aj$ExplicitlyInitializedClassLoaderWeavingAdaptor@f25f89
[AJ] Weaver adaptors after queue processing:
[AJ] org.aspectj.weaver.loadtime.Aj$AdaptorKey@353b6107 = org.aspectj.weaver.loadtime.Aj$ExplicitlyInitializedClassLoaderWeavingAdaptor@f25f89
[AJ] Weaver adaptors before queue processing:
[AJ] org.aspectj.weaver.loadtime.Aj$AdaptorKey@353b6107 = org.aspectj.weaver.loadtime.Aj$ExplicitlyInitializedClassLoaderWeavingAdaptor@f25f89
[AJ] Weaver adaptors after queue processing:
[AJ] org.aspectj.weaver.loadtime.Aj$AdaptorKey@353b6107 = org.aspectj.weaver.loadtime.Aj$ExplicitlyInitializedClassLoaderWeavingAdaptor@f25f89
[stopwatch] [repeat: 3, time: 8.750 sec]
[echo] ---- ITERATION 4 ----
[AJ] [WeaveClassLoaderImpl@db06de] info AspectJ Weaver Version 1.6.1 built on Thursday Jul 3, 2008 at 18:35:41 GMT
[AJ] [WeaveClassLoaderImpl@db06de] info register classloader com.ctc..ant.WeaveClassLoaderImpl@db06de
[AJ] [WeaveClassLoaderImpl@db06de] info using configuration file:/D:/works/weaver/antjunit-aspect.jar!/M
[AJ] [WeaveClassLoaderImpl@db06de] info register aspect com.ctc.aspects.TestAspect
[AJ] [2008-07-24 11:14:24] BEGIN tests.TestFoo.testOne
[AJ] [2008-07-24 11:14:24] SUCCESS tests.TestFoo.testOne
[AJ] [2008-07-24 11:14:24] BEGIN tests.TestFoo.testTimeout
[AJ] [2008-07-24 11:14:24] SUCCESS tests.TestFoo.testTimeout
[AJ] [2008-07-24 11:14:24] BEGIN tests.TestFoo.testTwo
[AJ] [2008-07-24 11:14:24] SUCCESS tests.TestFoo.testTwo
[AJ] Weaver adaptors before queue processing:
[AJ] org.aspectj.weaver.loadtime.Aj$AdaptorKey@1fa7fe16 = org.aspectj.weaver.loadtime.Aj$ExplicitlyInitializedClassLoaderWeavingAdaptor@18d77b
[AJ] Weaver adaptors after queue processing:
[AJ] org.aspectj.weaver.loadtime.Aj$AdaptorKey@1fa7fe16 = org.aspectj.weaver.loadtime.Aj$ExplicitlyInitializedClassLoaderWeavingAdaptor@18d77b
[AJ] Weaver adaptors before queue processing:
[AJ] org.aspectj.weaver.loadtime.Aj$AdaptorKey@1fa7fe16 = org.aspectj.weaver.loadtime.Aj$ExplicitlyInitializedClassLoaderWeavingAdaptor@18d77b
[AJ] Weaver adaptors after queue processing:
[AJ] org.aspectj.weaver.loadtime.Aj$AdaptorKey@1fa7fe16 = org.aspectj.weaver.loadtime.Aj$ExplicitlyInitializedClassLoaderWeavingAdaptor@18d77b
[stopwatch] [repeat: 4, time: 8.437 sec]
[echo] ---- ITERATION 5 ----
[AJ] [WeaveClassLoaderImpl@1115340] info AspectJ Weaver Version 1.6.1 built on Thursday Jul 3, 2008 at 18:35:41 GMT
[AJ] [WeaveClassLoaderImpl@1115340] info register classloader com.ctc..ant.WeaveClassLoaderImpl@1115340
[AJ] [WeaveClassLoaderImpl@1115340] info using configuration file:/D:/works/weaver/antjunit-aspect.jar!/
[AJ] [WeaveClassLoaderImpl@1115340] info register aspect com.ctc.aspects.TestAspect
[AJ] [2008-07-24 11:14:32] BEGIN tests.TestFoo.testOne
[AJ] [2008-07-24 11:14:32] SUCCESS tests.TestFoo.testOne
[AJ] [2008-07-24 11:14:32] BEGIN tests.TestFoo.testTimeout
[AJ] [2008-07-24 11:14:32] SUCCESS tests.TestFoo.testTimeout
[AJ] [2008-07-24 11:14:32] BEGIN tests.TestFoo.testTwo
[AJ] [2008-07-24 11:14:32] SUCCESS tests.TestFoo.testTwo
[AJ] Weaver adaptors before queue processing:
[AJ] org.aspectj.weaver.loadtime.Aj$AdaptorKey@27810840 = org.aspectj.weaver.loadtime.Aj$ExplicitlyInitializedClassLoaderWeavingAdaptor@1d07324
[AJ] Weaver adaptors after queue processing:
[AJ] org.aspectj.weaver.loadtime.Aj$AdaptorKey@27810840 = org.aspectj.weaver.loadtime.Aj$ExplicitlyInitializedClassLoaderWeavingAdaptor@1d07324
[AJ] Weaver adaptors before queue processing:
[AJ] org.aspectj.weaver.loadtime.Aj$AdaptorKey@27810840 = org.aspectj.weaver.loadtime.Aj$ExplicitlyInitializedClassLoaderWeavingAdaptor@1d07324
[AJ] Weaver adaptors after queue processing:
[AJ] org.aspectj.weaver.loadtime.Aj$AdaptorKey@27810840 = org.aspectj.weaver.loadtime.Aj$ExplicitlyInitializedClassLoaderWeavingAdaptor@1d07324
[stopwatch] [repeat: 5, time: 7.984 sec]
[echo] ---- ITERATION 6 ----
[AJ] [WeaveClassLoaderImpl@f8ac14] info AspectJ Weaver Version 1.6.1 built on Thursday Jul 3, 2008 at 18:35:41 GMT
[AJ] [WeaveClassLoaderImpl@f8ac14] info register classloader com.ctc..ant.WeaveClassLoaderImpl@f8ac14
[AJ] [WeaveClassLoaderImpl@f8ac14] info using configuration file:/D:/works/weaver/antjunit-aspect.jar!/M
[AJ] [WeaveClassLoaderImpl@f8ac14] info register aspect com.ctc.aspects.TestAspect
[AJ] [2008-07-24 11:14:40] BEGIN tests.TestFoo.testOne
[AJ] [2008-07-24 11:14:40] SUCCESS tests.TestFoo.testOne
[AJ] [2008-07-24 11:14:40] BEGIN tests.TestFoo.testTimeout
[AJ] [2008-07-24 11:14:40] SUCCESS tests.TestFoo.testTimeout
[AJ] [2008-07-24 11:14:40] BEGIN tests.TestFoo.testTwo
[AJ] [2008-07-24 11:14:40] SUCCESS tests.TestFoo.testTwo
[AJ] Weaver adaptors before queue processing:
[AJ] org.aspectj.weaver.loadtime.Aj$AdaptorKey@23f0dee4 = org.aspectj.weaver.loadtime.Aj$ExplicitlyInitializedClassLoaderWeavingAdaptor@7d0820
[AJ] Weaver adaptors after queue processing:
[AJ] org.aspectj.weaver.loadtime.Aj$AdaptorKey@23f0dee4 = org.aspectj.weaver.loadtime.Aj$ExplicitlyInitializedClassLoaderWeavingAdaptor@7d0820
[AJ] Weaver adaptors before queue processing:
[AJ] org.aspectj.weaver.loadtime.Aj$AdaptorKey@23f0dee4 = org.aspectj.weaver.loadtime.Aj$ExplicitlyInitializedClassLoaderWeavingAdaptor@7d0820
[AJ] Weaver adaptors after queue processing:
[AJ] org.aspectj.weaver.loadtime.Aj$AdaptorKey@23f0dee4 = org.aspectj.weaver.loadtime.Aj$ExplicitlyInitializedClassLoaderWeavingAdaptor@7d0820
[stopwatch] [repeat: 6, time: 7.547 sec]
[echo] ---- ITERATION 7 ----
[AJ] [WeaveClassLoaderImpl@75323c] info AspectJ Weaver Version 1.6.1 built on Thursday Jul 3, 2008 at 18:35:41 GMT
[AJ] [WeaveClassLoaderImpl@75323c] info register classloader com.ctc..ant.WeaveClassLoaderImpl@75323c
[AJ] [WeaveClassLoaderImpl@75323c] info using configuration file:/D:/works/weaver/antjunit-aspect.jar!/M
[AJ] [WeaveClassLoaderImpl@75323c] info register aspect com.ctc.aspects.TestAspect
[AJ] [2008-07-24 11:14:49] BEGIN tests.TestFoo.testOne
[AJ] [2008-07-24 11:14:49] SUCCESS tests.TestFoo.testOne
[AJ] [2008-07-24 11:14:49] BEGIN tests.TestFoo.testTimeout
[AJ] [2008-07-24 11:14:49] SUCCESS tests.TestFoo.testTimeout
[AJ] [2008-07-24 11:14:49] BEGIN tests.TestFoo.testTwo
[AJ] [2008-07-24 11:14:49] SUCCESS tests.TestFoo.testTwo
[AJ] Weaver adaptors before queue processing:
[AJ] org.aspectj.weaver.loadtime.Aj$AdaptorKey@10f042ac = org.aspectj.weaver.loadtime.Aj$ExplicitlyInitializedClassLoaderWeavingAdaptor@95b0a3
[AJ] Weaver adaptors after queue processing:
[AJ] org.aspectj.weaver.loadtime.Aj$AdaptorKey@10f042ac = org.aspectj.weaver.loadtime.Aj$ExplicitlyInitializedClassLoaderWeavingAdaptor@95b0a3
[AJ] Weaver adaptors before queue processing:
[AJ] org.aspectj.weaver.loadtime.Aj$AdaptorKey@10f042ac = org.aspectj.weaver.loadtime.Aj$ExplicitlyInitializedClassLoaderWeavingAdaptor@95b0a3
[AJ] Weaver adaptors after queue processing:
[AJ] org.aspectj.weaver.loadtime.Aj$AdaptorKey@10f042ac = org.aspectj.weaver.loadtime.Aj$ExplicitlyInitializedClassLoaderWeavingAdaptor@95b0a3
[stopwatch] [repeat: 7, time: 9.234 sec]
[echo] ---- ITERATION 8 ----
On Thu, Jul 24, 2008 at 8:37 AM, <
aspectj-users-request@xxxxxxxxxxx> wrote:
Send aspectj-users mailing list submissions to
aspectj-users@xxxxxxxxxxx
To subscribe or unsubscribe via the World Wide Web, visit
https://dev.eclipse.org/mailman/listinfo/aspectj-users
or, via email, send a message with subject or body 'help' to
aspectj-users-request@xxxxxxxxxxx
You can reach the person managing the list at
aspectj-users-owner@xxxxxxxxxxx
When replying, please edit your Subject line so it is more specific
than "Re: Contents of aspectj-users digest..."
Today's Topics:
1. Re: Static Analysis, BCEL and aspectj (Andy Clement)
2. Re: Regarding worm whole implementation (Andy Clement)
3. Re: Re: LTW (load time weaving) with Aj throws
OutOfMemoryError (Andy Clement)
----------------------------------------------------------------------
Message: 1
Date: Wed, 23 Jul 2008 17:14:00 -0700
From: "Andy Clement" <andrew.clement@xxxxxxxxx>
Subject: Re: [aspectj-users] Static Analysis, BCEL and aspectj
To: aspectj-users@xxxxxxxxxxx
Message-ID:
<689d61aa0807231714h3a79ae30t14f5763e406374e4@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset="iso-8859-1"
> What libraries should I use, if I want to do some bytecode level
> engineering and still use aspectj?
I would probably use ASM to modify bytecode at a low level if that is what
you want to do, AspectJ will still work on whatever the end result is, you
just have to realise that you may have introduced or removed join points
that may affect what your pointcuts match.
Andy.
2008/7/23 Andrew Eisenberg <andrew@xxxxxxxxxxxx>:
> 1. *Some* forms of static analysis are possible. See declare error
> and declare warning. I can't say if it will address your specific
> need, however.
>
> 2. There is a long history to this and this question occasionally
> crops up on this list. There are at least two answers to this (and
> Andy may be able to give some more detail than I can). First, it is
> difficult to implement properly and cleanly. From a language design
> point of view, picking out join points on code blocks is difficult to
> specify succinctly since they are not named. Second, when pressed for
> details, most people who request the language feature do not have a
> general purpose reason for wanting it (rather it is quite specific to
> the feature requestor's purposes.
>
> Because of answer #1, there must be a very strong use case. That
> being said, there may be some strong use cases that have not been
> considered and you may know what they are.
>
>
> --a
>
>
>
> On Tue, Jul 22, 2008 at 6:32 PM, 100ji <itz100ji@xxxxxxxxx> wrote:
> > Hi all,
> >
> > I have a few novice questions about aspectj.
> >
> > 1) Why can't aspectj be used to perform *some* forms of static
> > analysis? For example, for a given source code, I need to find if the
> > code has any calls to java.io.ObjectInputStream.readObject and the
> > type of object being read if any calls exist. I can use a static
> > analysis tool like PMD to find this out, but writing a tree walker is
> > extra work when aspectj knows how to do it. Why can I not write
> > something like a compile_time_pointcut and compile_time_advice to
> > specify this? Since aspectj already knows how to match patterns it can
> > give me the points I am interested in during compile time and run the
> > compile_time_advice. I understand that this approach is not as
> > powerful as one would like it to be, but this seems like a better
> > approach then the existing tools. I am not aware if any of the static
> > analysis tools can match patterns using a pointcut like syntax, so
> > this seemed like a useful addition.
> >
> > 2) Why is there no support for join points at a line level? For
> > example, I want to write an advice before or after the true condition
> > block of the if clause. Is there any fundamental reason why this is
> > not possible in aspectj? IIRC I can do this using BCEL or other byte
> > code engineering libraries. But, I heard that using 2 instrumentation
> > tools on the same code is a bad idea (ex: aspectj and BCEL) since
> > either of them may not understand the instrumentation made by the
> > other. What do people do when they have to instrument code at a low
> > level and still have to use aspectj. What libraries should I use, if
> > I want to do some bytecode level engineering and still use aspectj?
> >
> > TIA,
> > -S-
> > _______________________________________________
> > aspectj-users mailing list
> > aspectj-users@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/aspectj-users
> >
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://dev.eclipse.org/mailman/private/aspectj-users/attachments/20080723/a58b6174/attachment.html
------------------------------
Message: 2
Date: Wed, 23 Jul 2008 17:18:36 -0700
From: "Andy Clement" <andrew.clement@xxxxxxxxx>
Subject: Re: [aspectj-users] Regarding worm whole implementation
To: aspectj-users@xxxxxxxxxxx
Message-ID:
<689d61aa0807231718l5ca79d16gc391167a8720bbfc@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset="iso-8859-1"
I would say you probably have to manage the state yourself - so implement
the worm whole pattern yourself. When getUser() returns, stash whatever it
is in Threadlocal then when createCustomer() is invoked you can retrieve it
from ThreadLocal. There is no way to express what you want with cflow() as
createCustomer() does not happen in the control flow of getUser() (as you
observe). tracecuts in abc might do what you want, but I'm no expert on
those. Maybe Eric will comment.
Andy.
2008/7/23 Mritunjay Kumar <mritunjayonemail@xxxxxxxxx>:
> Our requirement is to implement worm whole pattern using aspectj.
> We are able to do it when caller and callee are in same cflow.
> But suppose we have one method 'getUser()', when getUser() method returns,
> after that we are calling customerService.createCustomer().
> the other end of worm hole comes in customerService.createCustomer()
> execution flow.
> Is there any way we can make the getUser() as the first point cut or our
> question is that 'is there any way to implement worm whole apttern even
> thouh caller and callee are not in same control flow".
> Please give suggestion on it as soon as possible.
>
> Regards,
> Mritunjay
>
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://dev.eclipse.org/mailman/private/aspectj-users/attachments/20080723/5d5e878e/attachment.html
------------------------------
Message: 3
Date: Wed, 23 Jul 2008 17:37:32 -0700
From: "Andy Clement" <andrew.clement@xxxxxxxxx>
Subject: Re: [aspectj-users] Re: LTW (load time weaving) with Aj
throws OutOfMemoryError
To: aspectj-users@xxxxxxxxxxx
Message-ID:
<689d61aa0807231737p1aea1343r12e62f41c513b5b6@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset="iso-8859-1"
2008/7/23 Anfernee Xu <anfernee.xu@xxxxxxxxx>:
> The output of console shows
>
> [WeaveClassLoaderImpl@c625f0] info AspectJ Weaver Version 1.6.1 built on
> Thursday Jul 3, 2008 at 18:35:41 GMT
> [WeaveClassLoaderImpl@c625f0] info register classloader
> com.ctc.ant.WeaveClassLoaderImpl@c625f0
> [WeaveClassLoaderImpl@c625f0] info using configuration
> file:/D:/test/aj-transformer.jar!/META-INF/aop.xml
> [WeaveClassLoaderImpl@c625f0] info register aspect
> com.ctc.aspects.TransformerAspect
>
> Transforming class ...
>
> Weaver adaptors before queue processing:
> org.aspectj.weaver.loadtime.Aj$AdaptorKey@1ca37bb0 =
> org.aspectj.weaver.loadtime.Aj$ExplicitlyInitializedClassLoaderWeavingAdaptor@e50bb4
> Weaver adaptors after queue processing:
> org.aspectj.weaver.loadtime.Aj$AdaptorKey@1ca37bb0 =
> org.aspectj.weaver.loadtime.Aj$ExplicitlyInitializedClassLoaderWeavingAdaptor@e50bb4
> Weaver adaptors before queue processing:
> org.aspectj.weaver.loadtime.Aj$AdaptorKey@1ca37bb0 =
> org.aspectj.weaver.loadtime.Aj$ExplicitlyInitializedClassLoaderWeavingAdaptor@e50bb4
> Weaver adaptors after queue processing:
> org.aspectj.weaver.loadtime.Aj$AdaptorKey@1ca37bb0 =
> org.aspectj.weaver.loadtime.Aj$ExplicitlyInitializedClassLoaderWeavingAdaptor@e50bb4
>
Do you find it always just reporting one entry? The list of weaver adaptors
is the effectively the list of classloaders that are currently hard
referenced in the VM and whose weavers cannot be cleaned up because the
loaders still might get used.
If you tell me you are constantly recycling classloaders then the fact that
there is only one entry in weaver adaptors map is a good thing, since it
means older ones are being tidied up - however the reference ID for the live
one ought to be changing over time
(the ExplicitlyInitializedClassLoaderWeavingAdaptor@e50bb4) otherwise there
is just one long running one - and that is when you could run out of memory
because weavers do not shrink over time. This is bug 227484.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=227484
> I have made a hack in my application so that each call will result in
creating a
> chunk of objects per classloader, and I did not find my classloader has
memory leak.
What did you do? Did you have a weaver associated with your loader and run
it outside of an Ant environment? Or did you just run your loader without a
weaver instance? The former is what I'd be more interested in.
> BTW, my application will create a new classloader for each request, and in
turn a new Aj will be created.
So the ID of the live entry in the weaver adaptor list ought to constantly
change after each call to that API - is that true?
As I said before, I can't really do anything unless you tell me who has the
hard reference to the classloader instance that is preventing tidy up. For
1.6.1 I wrapped all classloader references within the weaver inside
WeakReferences - so their existence will not prevent GC of the classloader
object. So if the weavers are not being tidied up it means something else
has a hard reference to the classloader object - if we find out what that is
we can break the reference. Does your profiler tell you that? Maybe you
want to raise a bugzilla entry whilst we investigate this, rather than
everyone having to read about classloaders. But as far as I'm aware there
are no non-weakreference wrapped classloader references in the weaver now
and so nothing that can cause weavers to live longer than their associated
classloaders.
cheers,
Andy.
>
>
>
> Anfernee
>
>
>
> On Wed, Jul 23, 2008 at 11:25 AM, <aspectj-users-request@xxxxxxxxxxx>
> wrote:
>
>> Send aspectj-users mailing list submissions to
>> aspectj-users@xxxxxxxxxxx
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>> or, via email, send a message with subject or body 'help' to
>> aspectj-users-request@xxxxxxxxxxx
>>
>> You can reach the person managing the list at
>> aspectj-users-owner@xxxxxxxxxxx
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of aspectj-users digest..."
>>
>>
>> Today's Topics:
>>
>> 1. Re: LTW (load time weaving) with Aj throws OutOfMemoryError
>> (Andy Clement)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Tue, 22 Jul 2008 20:25:14 -0700
>> From: "Andy Clement" <andrew.clement@xxxxxxxxx>
>> Subject: Re: [aspectj-users] LTW (load time weaving) with Aj throws
>> OutOfMemoryError
>> To: aspectj-users@xxxxxxxxxxx
>> Message-ID:
>> <689d61aa0807222025wef1a8d3iedc8167302f36d30@xxxxxxxxxxxxxx>
>>
>> Content-Type: text/plain; charset="iso-8859-1"
>>
>> Also, you didn't tell me the output produced for making that API call.
>> Passing 'true' means it should tell you the size of the weaveradaptor set
>> and whether it is managing to clean it up? (to stdout)
>>
>> Andy.
>>
>> 2008/7/22 Anfernee Xu <anfernee.xu@xxxxxxxxx>:
>>
>> > Thanks Andy for your information.
>> >
>> > I tried the API call
>> > org.aspectj.weaver.loadtime.Aj.removeStaleAdaptors(true)
>> >
>> > but it does not help, the memory still bloats, I ran a profiler to
>> monitor
>> > the possible memory leak,
>> > between two time slides, I can see the following instances constantly
>> going
>> > up.
>> >
>> > static variable org.aspectj.apache.bcel.util.
>> > ClassLoaderRepository.sharedCache
>> >
>> > and
>> >
>> > static variable
>> > org.aspectj.weaver.loadtime.Aj$WeaverContainer.weavingAdaptors
>> >
>> > Hope it can help you find out what's going wrong.
>> >
>> > If you need any further information, feel free to ask me.
>> >
>> > Thanks for your help.
>> >
>> > Anfernee
>> >
>> >
>> > On Wed, Jul 23, 2008 at 11:03 AM, Anfernee Xu <anfernee.xu@xxxxxxxxx>
>> > wrote:
>> >
>> >> Thanks Andy for your information.
>> >>
>> >> I tried the API call
>> >> org.aspectj.weaver.loadtime.Aj.removeStaleAdaptors(true)
>> >>
>> >> but it does not help, the memory still bloats, I ran a profiler to
>> monitor
>> >> the possible memory leak,
>> >> between two time slides, I can see the following instances constantly
>> >> going up.
>> >>
>> >> static variable
>> >> org.aspectj.apache.bcel.util.ClassLoaderRepository.sharedCache
>> >>
>> >> and
>> >>
>> >> static variable
>> >> org.aspectj.weaver.loadtime.Aj$WeaverContainer.weavingAdaptors
>> >>
>> >> Hope it can help you find out what's going wrong.
>> >>
>> >> If you need any further information, feel free to ask me.
>> >>
>> >> Thanks for your help.
>> >>
>> >> Anfernee
>> >>
>> >>
>> >>
>> >> On Wed, Jul 23, 2008 at 1:33 AM, <aspectj-users-request@xxxxxxxxxxx>
>> >> wrote:
>> >>
>> >>> Send aspectj-users mailing list submissions to
>> >>> aspectj-users@xxxxxxxxxxx
>> >>>
>> >>> To subscribe or unsubscribe via the World Wide Web, visit
>> >>> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>> >>> or, via email, send a message with subject or body 'help' to
>> >>> aspectj-users-request@xxxxxxxxxxx
>> >>>
>> >>> You can reach the person managing the list at
>> >>> aspectj-users-owner@xxxxxxxxxxx
>> >>>
>> >>> When replying, please edit your Subject line so it is more specific
>> >>> than "Re: Contents of aspectj-users digest..."
>> >>>
>> >>>
>> >>> Today's Topics:
>> >>>
>> >>> 1. Re: Error building project with Eclipse+AJDT 1.5.2 (Andy Clement)
>> >>> 2. Re: LTW (load time weaving) with Aj throws
>> OutOfMemoryError
>> >>> (Andy Clement)
>> >>> 3. Static Analysis, BCEL and aspectj (100ji)
>> >>>
>> >>>
>> >>> ----------------------------------------------------------------------
>> >>>
>> >>> Message: 1
>> >>> Date: Tue, 22 Jul 2008 10:18:52 -0700
>> >>> From: "Andy Clement" <andrew.clement@xxxxxxxxx>
>> >>> Subject: Re: [aspectj-users] Error building project with Eclipse+AJDT
>> >>> 1.5.2
>> >>> To: aspectj-users@xxxxxxxxxxx
>> >>> Message-ID:
>> >>> <689d61aa0807221018n5ae0ed10r9fa295ca26db2a41@xxxxxxxxxxxxxx>
>> >>> Content-Type: text/plain; charset="iso-8859-1"
>> >>>
>> >>> Hi Walter,
>> >>>
>> >>> 2008/7/22 Walter Cazzola <cazzola@xxxxxxxxxxxxx>:
>> >>>
>> >>> > Hi Andy,
>> >>> > thanks a lot for the answer
>> >>> >
>> >>> > On Mon, 21 Jul 2008, Andy Clement wrote:
>> >>> >
>> >>> > There is a 64k size limit for methods in Java. Sometimes if an
>> >>> >> already large method contains many join points that match then
>> during
>> >>> >> weaving the size will grow past 64k. AspectJ does not do any
>> >>> >> splitting of the woven code into multiple methods in this case but
>> >>> >> just reports that it cannot weave that method.
>> >>> >>
>> >>> >
>> >>> > We was imaging something like this. Is there a way to work around
>> this
>> >>> > problem?
>> >>> >
>> >>>
>> >>> Only the workarounds you might imagine, there is no magic solution:
>> >>> - use withincode() to avoid weaving the method that will get too large
>> >>> with
>> >>> your general aspect and write specific advice for relevant join points
>> >>> within it.
>> >>> - use execution() matching advice rather than call() which might
>> advise
>> >>> fewer places
>> >>> - turn off advice inlining if using around advice, to reduce code
>> >>> inserted
>> >>> into advised methods
>> >>> - don't use non-static information available at the join point since
>> that
>> >>> must be packaged up and passed to the advice every time
>> >>>
>> >>>
>> >>> >
>> >>> > We are going to weave our aspects on third part applications and we
>> >>> > don't want to refactor their code since our aspects have the intent
>> to
>> >>> > determine what can be extracted and encapsulated in aspects (aspect
>> >>> > mining) but this sounds as a recursive problem.
>> >>>
>> >>>
>> >>> The correct solution is breaking the advised method into pieces when
>> it
>> >>> gets
>> >>> too large, but so far it happens infrequently enough that fixing it
>> >>> hasn't
>> >>> become a priority for us I'm afraid. In fact I don't even think we
>> have
>> >>> an
>> >>> open bug request to address it - feel free to raise one but I'm not
>> sure
>> >>> we'll get to it soon.
>> >>>
>> >>> cheers,
>> >>> Andy.
>> >>>
>> >>>
>> >>>
>> >>> >
>> >>> >
>> >>> > Cheers
>> >>> > Walter
>> >>> >
>> >>> > --
>> >>> > Walter Cazzola, PhD - Assistant Professor, DICo, University of
>> Milano
>> >>> > E-mail cazzola@xxxxxxxxxxxxx Ph.: +39 02 503 16300 Fax: +39 02 503
>> >>> 16100
>> >>> > · · · ---------------------------- · · ·
>> ---------------------------- ·
>> >>> · ·
>> >>> > ... recursive: adjective, see recursive ...
>> >>> > · · · ---------------------------- · · ·
>> ---------------------------- ·
>> >>> · ·
>> >>> > _______________________________________________
>> >>> > aspectj-users mailing list
>> >>> > aspectj-users@xxxxxxxxxxx
>> >>> > https://dev.eclipse.org/mailman/listinfo/aspectj-users
>> >>> >
>> >>> >
>> >>> -------------- next part --------------
>> >>> An HTML attachment was scrubbed...
>> >>> URL:
>> >>>
>> https://dev.eclipse.org/mailman/private/aspectj-users/attachments/20080722/93aa98b5/attachment.html
>> >>>
>> >>> ------------------------------
>> >>>
>> >>> Message: 2
>> >>> Date: Tue, 22 Jul 2008 10:28:14 -0700
>> >>> From: "Andy Clement" <andrew.clement@xxxxxxxxx>
>> >>> Subject: Re: [aspectj-users] LTW (load time weaving) with Aj throws
>> >>> OutOfMemoryError
>> >>> To: aspectj-users@xxxxxxxxxxx
>> >>> Message-ID:
>> >>> <689d61aa0807221028y34115351r26c54fa85a214179@xxxxxxxxxxxxxx>
>> >>> Content-Type: text/plain; charset="iso-8859-1"
>> >>>
>> >>> > My Ant task will destroy the classloader which creates Aj after each
>> >>> processing. It looks to me the
>> >>> > loaded/transformed classes is not clean up when the classloader is
>> >>> destroyed.
>> >>> > I used the latest AspectJ relase, 1.6.1
>> >>>
>> >>> I specifically tested that tidy up is occurring with 1.6.1 and all my
>> >>> scenarios confirm it - however that is doing loadtime weaving the
>> regular
>> >>> way. I have seen problems with Ant where classloaders have not been
>> >>> released, even when you think they must have. Can you run your
>> >>> classloader
>> >>> in a regular Java scenario outside of Ant and confirm whether it
>> behaves?
>> >>>
>> >>> There is an API call
>> >>>
>> >>> org.aspectj.weaver.loadtime.Aj.removeStaleAdaptors(true)
>> >>>
>> >>> that will attempt to remove weavers attached to stale classloaders.
>> Try
>> >>> calling that and seeing what output you get - if they cannot be tidied
>> up
>> >>> then the classloaders have not been orphaned. In that case collect
>> some
>> >>> hprof profiling output and use something like (j)hat to see who is
>> >>> holding
>> >>> on to references to them. If it is the weaver then I have a bug to
>> fix.
>> >>>
>> >>> What is still a problem is that over time the weaver instances will
>> get
>> >>> larger and larger and never shrink - we have an open bug report for
>> that.
>> >>> But if you are constantly using different classloaders (and so
>> different
>> >>> weaver instances) then they will come and go and never grow out of
>> >>> control.
>> >>>
>> >>> Andy.
>> >>>
>> >>>
>> >>> 2008/7/22 Anfernee Xu <anfernee.xu@xxxxxxxxx>:
>> >>>
>> >>> > Hi,
>> >>> >
>> >>> > I'm developing an Ant task which will use LTW to enhance the classes
>> >>> > specified in <classpath> nested element of my Ant task. Basically, I
>> >>> create
>> >>> > a subclass of AntClassLoader, the classloader is at the bottom of
>> >>> > classloader tree. and use org.aspectj.weaver.loadtime.Aj to perform
>> >>> LTW,
>> >>> > here's my ClassLoader code snippet,
>> >>> >
>> >>> > class WeaveClassLoader extends AntClassLoader {
>> >>> >
>> >>> > // aspectj byte-code transformer
>> >>> > protected Aj transformer = null;
>> >>> >
>> >>> > // whether need byte-code transformer.
>> >>> > protected boolean isAjOn = false;
>> >>> >
>> >>> > @Override
>> >>> > protected final Class defineClassFromData(File container, byte[]
>> >>> > classData,
>> >>> > String classname) throws IOException {
>> >>> >
>> >>> > byte[] classBytes = transform(classname, classData, this);
>> >>> > return super.defineClassFromData(container, classBytes,
>> classname);
>> >>> >
>> >>> > }
>> >>> >
>> >>> > protected byte[] transform(String classname, byte[] byteCode,
>> >>> > ClassLoader classloader) {
>> >>> > if (isTransformerTurnOn() && isWeavedClass(classname))
>> >>> > return transformer.preProcess(classname, byteCode, this);
>> >>> > return byteCode;
>> >>> > }
>> >>> >
>> >>> >
>> >>> > @Override
>> >>> > protected synchronized Class loadClass(String classname, boolean
>> >>> resolve)
>> >>> > throws ClassNotFoundException {
>> >>> > Class theClass = findLoadedClass(classname);
>> >>> > if (theClass != null) {
>> >>> > return theClass;
>> >>> > }
>> >>> > if (isSplit(classname) || isAspect(classname)) {
>> >>> > theClass = findClass(classname);
>> >>> > if (resolve) {
>> >>> > resolveClass(theClass);
>> >>> > }
>> >>> >
>> >>> > } else {
>> >>> > theClass = super.loadClass(classname, resolve);
>> >>> > }
>> >>> >
>> >>> > return theClass;
>> >>> > }
>> >>> >
>> >>> > The function run pretty well, but over time, it consumed more memory
>> >>> and
>> >>> > eventually threw OutOfMemory and aborted.
>> >>> >
>> >>> > The stacktrace is as follows,
>> >>> >
>> >>> > testErrorHandling_exceptiontype:
>> >>> > Jul 20, 2008 2:36:10 PM org.aspectj.weaver.tools.Jdk14Trace error
>> >>> > SEVERE: junit.framework.Test
>> >>> > java.lang.OutOfMemoryError: CG(q0)
>> >>> > [org/aspectj/apache/bcel/Constants.<clinit>()V] JVM@cgFail
>> (src/jvm/code/codemanager.c:693).
>> >>> Java heapsize=604577792, pa
>> >>> > at
>> >>> >
>> >>>
>> org.aspectj.apache.bcel.classfile.Attribute.readAttribute(Attribute.java:177)
>> >>> > at
>> >>> >
>> >>>
>> org.aspectj.apache.bcel.classfile.FieldOrMethod.<init>(FieldOrMethod.java:111)
>> >>> > at
>> org.aspectj.apache.bcel.classfile.Field.<init>(Field.java:83)
>> >>> > at
>> >>> >
>> >>>
>> org.aspectj.apache.bcel.classfile.ClassParser.readFields(ClassParser.java:280)
>> >>> > at
>> >>> >
>> >>>
>> org.aspectj.apache.bcel.classfile.ClassParser.parse(ClassParser.java:172)
>> >>> > at
>> >>> >
>> >>>
>> org.aspectj.apache.bcel.util.ClassLoaderRepository.loadClass(ClassLoaderRepository.java:288)
>> >>> > at
>> >>> >
>> org.aspectj.weaver.bcel.BcelWorld.lookupJavaClass(BcelWorld.java:369)
>> >>> > at
>> >>> >
>> org.aspectj.weaver.bcel.BcelWorld.resolveDelegate(BcelWorld.java:338)
>> >>> > at
>> >>> org.aspectj.weaver.ltw.LTWWorld.resolveDelegate(LTWWorld.java:97)
>> >>> > at
>> org.aspectj.weaver.World.resolveToReferenceType(World.java:378)
>> >>> > at org.aspectj.weaver.World.resolve(World.java:271)
>> >>> > at
>> >>> >
>> >>>
>> org.aspectj.weaver.bcel.BcelWeaver.addLibraryAspect(BcelWeaver.java:165)
>> >>> > at
>> >>> >
>> >>>
>> org.aspectj.weaver.loadtime.ClassLoaderWeavingAdaptor.registerAspects(ClassLoaderWeavingAdaptor.java:399)
>> >>> > at
>> >>> >
>> >>>
>> org.aspectj.weaver.loadtime.ClassLoaderWeavingAdaptor.registerDefinitions(ClassLoaderWeavingAdaptor.java:240)
>> >>> > at
>> >>> >
>> >>>
>> org.aspectj.weaver.loadtime.ClassLoaderWeavingAdaptor.initialize(ClassLoaderWeavingAdaptor.java:152)
>> >>> > at
>> >>> >
>> >>>
>> org.aspectj.weaver.loadtime.Aj$ExplicitlyInitializedClassLoaderWeavingAdaptor.initialize(Aj.java:151)
>> >>> > at
>> >>> >
>> >>>
>> org.aspectj.weaver.loadtime.Aj$ExplicitlyInitializedClassLoaderWeavingAdaptor.getWeavingAdaptor(Aj.java:156)
>> >>> > at
>> >>> >
>> org.aspectj.weaver.loadtime.Aj$WeaverContainer.getWeaver(Aj.java:122)
>> >>> > at org.aspectj.weaver.loadtime.Aj.preProcess(Aj.java:73)
>> >>> > .....
>> >>> > Jul 20, 2008 2:36:10 PM org.aspectj.weaver.tools.Jdk14Trace info
>> >>> > INFO: Dumping to .\ajcore.20080720.143610.453.txt
>> >>> > 302
>> >>> >
>> >>>
>> tests.functional.webapp.servlet25.clarifications.client.TestClarifications.testClarifications
>> >>> > (junit)
>> >>> > testErrorHandling_errorcode:
>> >>> > Jul 20, 2008 2:36:12 PM org.aspectj.weaver.tools.Jdk14Trace error
>> >>> > SEVERE: junit.framework.Test
>> >>> > java.lang.OutOfMemoryError: class allocation, 967086156 loaded,
>> >>> 893648896
>> >>> > footprint JVM@check_alloc(src/jvm/model/classload/classalloc.c:118).
>> >>> 5841
>> >>> > bytes
>> >>> > at java.lang.ClassLoader.defineClass1(Native Method)
>> >>> > at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
>> >>> > at
>> >>> >
>> >>>
>> org.apache.tools.ant.loader.AntClassLoader2.defineClassFromData(AntClassLoader2.java:78)
>> >>> > at
>> >>> >
>> >>>
>> org.apache.tools.ant.AntClassLoader.getClassFromStream(AntClassLoader.java:1090)
>> >>> > at
>> >>> >
>> >>>
>> org.apache.tools.ant.AntClassLoader.findClassInComponents(AntClassLoader.java:1154)
>> >>> > at
>> >>> >
>> org.apache.tools.ant.AntClassLoader.loadClass(AntClassLoader.java:984)
>> >>> > at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
>> >>> > at
>> >>> >
>> >>>
>> org.aspectj.weaver.loadtime.ClassLoaderWeavingAdaptor.initialize(ClassLoaderWeavingAdaptor.java:140)
>> >>> > at
>> >>> >
>> >>>
>> org.aspectj.weaver.loadtime.Aj$ExplicitlyInitializedClassLoaderWeavingAdaptor.initialize(Aj.java:151)
>> >>> > at
>> >>> >
>> >>>
>> org.aspectj.weaver.loadtime.Aj$ExplicitlyInitializedClassLoaderWeavingAdaptor.getWeavingAdaptor(Aj.java:157)
>> >>> > at
>> >>> >
>> org.aspectj.weaver.loadtime.Aj$WeaverContainer.getWeaver(Aj.java:122)
>> >>> > at org.aspectj.weaver.loadtime.Aj.preProcess(Aj.java:73)
>> >>> >
>> >>> >
>> >>> >
>> >>> > My Ant task will destroy the classloader which creates Aj after each
>> >>> > processing. It looks to me the loaded/transformed classes is not
>> clean
>> >>> up
>> >>> > when the classloader is destroyed.
>> >>> > I used the latest AspectJ relase, 1.6.1
>> >>> >
>> >>> > Any help is appreciated.
>> >>> >
>> >>> > Anfernee
>> >>> >
>> >>> > _______________________________________________
>> >>> > aspectj-users mailing list
>> >>> > aspectj-users@xxxxxxxxxxx
>> >>> > https://dev.eclipse.org/mailman/listinfo/aspectj-users
>> >>> >
>> >>> >
>> >>> -------------- next part --------------
>> >>> An HTML attachment was scrubbed...
>> >>> URL:
>> >>>
>> https://dev.eclipse.org/mailman/private/aspectj-users/attachments/20080722/a6de41b0/attachment.html
>> >>>
>> >>> ------------------------------
>> >>>
>> >>> Message: 3
>> >>> Date: Tue, 22 Jul 2008 13:32:56 -0400
>> >>> From: 100ji <itz100ji@xxxxxxxxx>
>> >>> Subject: [aspectj-users] Static Analysis, BCEL and aspectj
>> >>> To: aspectj-users@xxxxxxxxxxx
>> >>> Message-ID:
>> >>> <496ed55f0807221032p37836435je1515b6755d80af9@xxxxxxxxxxxxxx>
>> >>> Content-Type: text/plain; charset=ISO-8859-1
>> >>>
>> >>> Hi all,
>> >>>
>> >>> I have a few novice questions about aspectj.
>> >>>
>> >>> 1) Why can't aspectj be used to perform *some* forms of static
>> >>> analysis? For example, for a given source code, I need to find if the
>> >>> code has any calls to java.io.ObjectInputStream.readObject and the
>> >>> type of object being read if any calls exist. I can use a static
>> >>> analysis tool like PMD to find this out, but writing a tree walker is
>> >>> extra work when aspectj knows how to do it. Why can I not write
>> >>> something like a compile_time_pointcut and compile_time_advice to
>> >>> specify this? Since aspectj already knows how to match patterns it can
>> >>> give me the points I am interested in during compile time and run the
>> >>> compile_time_advice. I understand that this approach is not as
>> >>> powerful as one would like it to be, but this seems like a better
>> >>> approach then the existing tools. I am not aware if any of the static
>> >>> analysis tools can match patterns using a pointcut like syntax, so
>> >>> this seemed like a useful addition.
>> >>>
>> >>> 2) Why is there no support for join points at a line level? For
>> >>> example, I want to write an advice before or after the true condition
>> >>> block of the if clause. Is there any fundamental reason why this is
>> >>> not possible in aspectj? IIRC I can do this using BCEL or other byte
>> >>> code engineering libraries. But, I heard that using 2 instrumentation
>> >>> tools on the same code is a bad idea (ex: aspectj and BCEL) since
>> >>> either of them may not understand the instrumentation made by the
>> >>> other. What do people do when they have to instrument code at a low
>> >>> level and still have to use aspectj. What libraries should I use, if
>> >>> I want to do some bytecode level engineering and still use aspectj?
>> >>>
>> >>> TIA,
>> >>> -S-
>> >>>
>> >>>
>> >>> ------------------------------
>> >>>
>> >>> _______________________________________________
>> >>> aspectj-users mailing list
>> >>> aspectj-users@xxxxxxxxxxx
>> >>> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>> >>>
>> >>>
>> >>> End of aspectj-users Digest, Vol 41, Issue 34
>> >>> *********************************************
>> >>>
>> >>
>> >>
>> >>
>> >> --
>> >> --Anfernee
>> >>
>> >
>> >
>> >
>> > --
>> > --Anfernee
>> >
>> > _______________________________________________
>> > aspectj-users mailing list
>> > aspectj-users@xxxxxxxxxxx
>> > https://dev.eclipse.org/mailman/listinfo/aspectj-users
>> >
>> >
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL:
>> https://dev.eclipse.org/mailman/private/aspectj-users/attachments/20080722/7a64227c/attachment.html
>>
>> ------------------------------
>>
>> _______________________________________________
>> aspectj-users mailing list
>> aspectj-users@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>>
>>
>> End of aspectj-users Digest, Vol 41, Issue 38
>> *********************************************
>>
>
>
>
> --
> --Anfernee
>
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://dev.eclipse.org/mailman/private/aspectj-users/attachments/20080723/181cb54c/attachment.html
------------------------------
_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users
End of aspectj-users Digest, Vol 41, Issue 42
*********************************************
--
--Anfernee
