[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [aspectj-users] Garbage collector behavior
|
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