| Re: [aspectj-users] Garbage collector behavior |
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