All,
Ron had brought up my name before as I found something similar. The
only difference was that my problem was related to compile time
performance for aspectj on large projects. At first my reaction to the
"other" Ron's comment were they do not apply. But in thinking about, I
do think they have bearing on what you are seeing here. At least in my
mind the LTW is essentially another compile, which means that the same
problems for aspecjt compiles persist into LTW. So my theory is that
compile junk is getting left around in memory and never getting release
because the JVM does not shutdown like it does during static compiles.
I know Andy and Matt did some analysis on my problem and it was related
to the number of join points that aspectj had to evaluate that was
causing the problem. In my opinion these problems still affect
aspectj. I know for a fact that a compile for me is still CPU and
memory intensive [3 to 5 minutes at 100% CPU and I have an Athlon 2500+
CPU and 1 GB of RAM with two 7200 RPM IDE drives]
So, I did a little experiment, I started up Eclipse fresh and it took
up 93MB of memory. Then I fired off an AJDT build and the memory
climbed to 247 MB. Then I fired off another AJDT compile with my
memory sitting at 247 MB and and it jumped to 320.5 MB. So just for
fun, I fired off 1 more compile and finally the memory situation
stabilized [but grew some] at 321 MB.
So my guess is that the compile cycle/LTW cycle is not properly
releasing internally stored information necessary to compile the code.
Just my 2 cents!
I hope this helps.
Ron
Ron Bodkin wrote:
I quite doubt that these join
point static part objects account for much of the 70% increase in
memory use Mathieu is seeing. As you say Matthew, using build-time
weaving to see how much overhead comes from LTW will be instructive.
Mathieu,
Yes. Whenever you use thisJoinPoint,
thisJoinPointStaticPart or thisEnclosingJoinPointStaticPart an object,
that persists for the lifetime of the woven class, is created to
represent the desired information. Using compile-time or binary weaving
will help determine the source of the memory overhead.
Matthew Webster
AOSD Project
Java Technology Centre, MP146
IBM Hursley Park, Winchester, SO21 2JN, England
Telephone: +44 196 2816139 (external) 246139 (internal)
Email: Matthew Webster/UK/IBM @ IBMGB, matthew_webster@xxxxxxxxxx
http://w3.hursley.ibm.com/~websterm/
Please respond to
aspectj-users@xxxxxxxxxxx
Sent by:
aspectj-users-bounces@xxxxxxxxxxx
To: aspectj-users@xxxxxxxxxxx
cc:
Subject: Re: [aspectj-users] Garbage collector
behavior
Gloups,
I have not tried the compiletime weaving yet. Do you think these memory
overheads will still happen when weaving at compile time ? These
JoinPoint.Static objects would still be created ?
Mathieu
>
> Ron,
>
> While you continue to load classes that are available for weaving
they
> will need to be resolved and the amount of byte-code that is held
may
> continue to rise. Also if you are doing profiling there will be a
lot
> of JoinPoint.Static part objects created. The weaver is not
> multithreaded so it won't be allocating objects in the background.
> Once we have worked out all the issues surrounding
> ReflectionBasedReferenceTypeDelegate objects we can look at
footprint
> again. After that we can look at releasing byte-code but that will
> take longer.
>
> Cheers
>
> Matthew Webster
> AOSD Project
> Java Technology Centre, MP146
> IBM Hursley Park, Winchester, SO21 2JN, England
> Telephone: +44 196 2816139 (external) 246139 (internal)
> Email: Matthew Webster/UK/IBM @ IBMGB, matthew_webster@xxxxxxxxxx
> http://w3.hursley.ibm.com/~websterm/
>
> Please respond to aspectj-users@xxxxxxxxxxx
>
> Sent by: aspectj-users-bounces@xxxxxxxxxxx
>
> To: <aspectj-users@xxxxxxxxxxx>
> cc:
> Subject: RE: [aspectj-users] Garbage collector behavior
>
>
> Hi Mathieu,
>
> I have also noticed this phenomenon, e.g., there's about a 20%
increase in
> memory footprint on start up of Tomcat. However, after I have run
a load
> test I have seen the memory overhead rise to 100%. Now the
interesting
> thing
> is that I see this effect even if I disable all my aspects at
runtime
> (with
> && if(enabled) tests). However, if I write a trivial
aspect that just
> prints
> a message on staticinitialization of classes and deploy only that
at
> load-time, I see a normal memory profile under load.
>
> I think the next step is to try to come up with a simplified
example that
> reproduces the issue we're both seeing... This will also help to
make sure
> it's not something like mistakenly holding on hard references in
the
> monitoring code (for both of us!)
>
> There isn't a lot that's been written about this subject, since
LTW is so
> new... You can see some related tracking bugs
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=112817
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=113511
>
>
>
> -----Original Message-----
> From: aspectj-users-bounces@xxxxxxxxxxx
> [mailto:aspectj-users-bounces@xxxxxxxxxxx] On Behalf Of Mathieu
LEMAIRE
> Sent: Wednesday, October 26, 2005 3:01 AM
> To: aspectj-users@xxxxxxxxxxx
> Subject: Re: [aspectj-users] Garbage collector behavior
>
> Actually, memory issues I encounter do not appear at class-loading
but
> at runtime... My statistics are done amongst N runs of our program,
> systematically discarding the first run to put JVM
optims/weaving/class
> loading aside.
>
> Could you imagine any reason why the memory management would be
affected
> by the LTWeaver ?
> Do you have any link describing the bytecode duplication you
mentioned ?
>
> Thanks a lot for your answers.
>
> --
> Mathieu
>
> Ron Bodkin wrote:
>
> >Hi Mathieu,
> >
> >I'm very aware of these issues. I'm working on a general
framework for
> >tracking performance in application using AspectJ
> >(https://glassbox-inspector.dev.java.net/). I have been
working with
> Alex
> >Vasseur and Matthew Webster to reduce the memory and startup
time
> overhead
> >of this. This, of course, builds on past work that Adrian
Colyer led with
> >Andy Clement and Ron DiFrango if memory serves me right.
> >
> >Anyhow, I believe that the next stage of reducing overhead is
Matthew's
> >promising idea of using reflective proxy delegates for already
loaded
> >classes instead of storing multiple copies of bytecode for
classes.
> This is
> >most easy to implement with bootstrap-loaded classes (think
rt.jar).
> >However, over time I think it will be important to have
cacheing and to
> >allow sharing of class-definition bytecodes when a class is
loaded.
> >
> >I'm very interested in your statistics on the GC affects of
LTW and
> want to
> >better understand where the extra memory is consumed.
> >
> >-----Original Message-----
> >
> >I'm implementing a framework to profile our program execution,
that is,
> >memory consumptions, durations...
> >I use aspectJ (LTW mode) to instrumentate my classes.
> >
> >Here is my problem..
> >I got memory issues when using aspectJ, comparing to a mode
where I
> >instrumentate my classes directly in the code (aspectJ is
completely
> >removed from this mode). Using aspectJ, memory consumptions of
my
> >program are much higher than without using it (eg 120Mo >
70Mo). Also
> >profiling garbage collections, it seems that the GC collects
much more
> >when aspectJ is off (eg 4.5s > 2.3s).
> >
> >Do you have any clue for that to happen ?
> >thanx !
> >
> >
>
>
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>
>------------------------------------------------------------------------
>
>_______________________________________________
>aspectj-users mailing list
>aspectj-users@xxxxxxxxxxx
>https://dev.eclipse.org/mailman/listinfo/aspectj-users
>
>
_______________________________________________
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
|