Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-users] Garbage collector behavior

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.


From: aspectj-users-bounces@xxxxxxxxxxx [mailto:aspectj-users-bounces@xxxxxxxxxxx] On Behalf Of Matthew Webster
Sent: Thursday, October 27, 2005 2:19 AM
To: aspectj-users@xxxxxxxxxxx
Subject: Re: [aspectj-users] Garbage collector behavior


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

Back to the top