Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-users] Memory consumption problems


Andy,

Thanks for your thorough reply on this one. From what you say I believe I can rely on the following:

1. The memory allocation aspectj is responsible for, is proportional to the number
of classes loaded in.

2. Much of the memory allocated is elligable for garbage collection anyway.

3. We are using 1.6.0, but it sounds like we should upgrade to 1.6.1 in order to get
even more of our memory back.

Cheers
- Ashley

aspectj-users-bounces@xxxxxxxxxxx wrote on 27/07/2008 04:30:52:

> Hi Ashley,
>
> Loadtime weaver instances attached to classloaders are still heavier
> than I would like them to be.  I've done a lot of work in 1.6.1 to
> ensure that once the loader is available for GC then the weaver is
> also available for GC - and that is working fine.  The problem
> remaining is covered in https://bugs.eclipse.org/bugs/show_bug.cgi?id=227484
> and that relates to weavers not shrinking over time once they have
> done their job.  Yes, as you put it:
>
> > Hopefully then, those bcel instances are just transitory in the
> LTW process and are immediately
> > ready for garbage collection when the new class bytecode is produced.
>
> that should be true but it isn't always.  Sometimes for a good
> reason (we hang onto aspects as we may need their bcel bytecode
> representation later, perhaps to inline into some class that gets
> loaded later).  Sometimes for a bad reason - where we have a poor
> implementation of equality that requires identity equality (==)
> rather than supporting equals() properly.  In this latter situation
> we can't currently discard some things because if they are needed
> again sometime later we cannot recover the identical previous
> object.  This situation is what bug 227484 is about - I would have
> liked to fit it into 1.6.1 but it did not have sufficient testing.
>
> > Without knowing more about them and if they will consume more
> memory with time, we can't proceed any further.
>
> There is no reason why it should consume more memory over time -
> unless you load more classes.  Once all your classes are loaded and
> have been woven, the weaver has no reason to get involved in
> anything further, it will just sit there on the 'off chance' that
> you might load a class further down the line.  As you will see in
> bug 227484 what should happen is that the memory is recovered from
> the weaver over time as it is required elsewhere in the VM.
>
> Ashley said:
> > The aspect we have created contains a stopwatch implementation and
> a logger and its cardinality is percflow so we get
> > one per service method call on our server. I was under the
> impression though that as soon as the method call is finished
> > any aspectj resources associated are eligable for garbage collection.
>
> Ken said:
> >  I'd be very surprised if it's aspectj holding references on percflow
> > -- it'd be a bug. Otherwise there'd be a large warning on it's use.
>
> yes, cflows are implemented using ThreadLocal, there is no magic.  
> If AspectJ was leaking memory through instances via percflow you
> would gradually run out of memory as the code was exercised and it
> would be a huge bug.  However, all the types on your list are
> nothing to do with runtime behaviour of the woven code, they only
> relate to the weaving process - which is what gives me the
> confidence to say the weaver footprint' won't get larger over time.
>  
> > I have no idea how aspectj works under the hood and I can't find
> much info through google either.
>
> There is a paper by Jim and Erik but it is quite old now.  I haven't
> had time to write more detailed notes on the internals just due to
> too much to do with upgrading to Java 6 and fixing open issues.
>
> > Since we are using LTW, my guess is that the aspectj class loading
> interceptor uses bcel to filter the
> > class files according to our aspects and in doing so creates the
> bcel instances below.
>
> Yep.  But although AspectJ does use bcel - it uses a highly
> optimized derivate variant of what is on the public bcel page.  So
> you can't really rely on that doc to give you much info.
>
> > However this is pure speculation based on 5 minutes at the bcel
> website and therefore
> > would like to find out a little more. I would definitely recommend
> at least one prominent
> > page on this sort of thing at eclipse.org, since surprises like
> this, even if it is benign, can
> > cause panic in organizations at the early adoption stage for aspectj.
>
> Discussion of weaver footprint comes up on the list periodically -
> and is what gave rise to bug 227484.  I try to talk about major
> changes in memory usage in the readme for releases (see the 1.6.1
> readme, for example, http://www.eclipse.
> org/aspectj/doc/released/README-161.html ) but I'll admit I haven't
> typically highlighted the current bugs that are open to cover future
> memory optimizations.  I don't typically like to add FAQ entries for
> bugs, which is what the large latent footprint is, but I know it is
> taking me a while to getting around to addressing it so perhaps it
> deserves one.
>
> > I would appreciate it if somebody could shed some light on this.
>
> Well I've had a first stab, if you need more info please ask away.  
> If you want to get an updated driver for 227484 and help me test
> whether it works, that would be great !  Also, I can't see mention
> of what version you are on, I hope you are on 1.6.1 due to all the
> ltw enhancements and fixes.
>
> cheers,
> Andy.

> 2008/7/25 Ashley Williams <ashley.williams@xxxxxx>
>
> Hi,
>
> We were looking forward to going to production with our profiling
> aspect however when we ran our app through jmap we got the chart
> pasted below. So it looks like some aspectj objects are responsible
> for a sizable share of memory. Without knowing more about them and
> if they will consume more memory with time, we can't proceed any further.
>
> The aspect we have created contains a stopwatch implementation and a
> logger and its cardinality is percflow so we get one per service
> method call on our server. I was under the impression though that as
> soon as the method call is finished any aspectj resources associated
> are eligable for garbage collection.
>
> I would appreciate it if somebody could shed some light on this.
>
> Cheers
> - Ashley Williams
>
> Size                 Count    Class
>
> 163466352       2149652 char[]
> 102393424       609786  byte[]
> 92017240        2300431 java.lang.String
> 43706328        114013  java.lang.Object[]
> 38792736        808182  java.util.HashMap$Entry
> 32742008        201623  int[]
> 32662680        269046  java.util.HashMap$Entry[]
> 31770768        234338  * ConstMethodKlass
> 26740224        417816  java.util.TreeMap$Entry
> 24387008        762094  org.aspectj.apache.bcel.classfile.ConstantUtf8
> 24380640        234338  * MethodKlass
> 18097728        188518  org.jboss.jms.message.JBossObjectMessage
> 17139712        267808  java.util.HashMap
> 16629528        13554   * ConstantPoolKlass
> 16087896        182817  org.aspectj.apache.bcel.classfile.Method
> 15182816        172532  org.aspectj.apache.bcel.classfile.Code
> 14216368        402768  org.aspectj.apache.bcel.classfile.Attribute[]
> 12472208        82054   java.lang.reflect.Method
> 11550800        13554   * InstanceKlassKlass
> 10796824        8196    org.aspectj.apache.bcel.classfile.Constant[]
> 10261296        199361  * SymbolKlass
> ---
>
> This e-mail may contain confidential and/or privileged information.
> If you are not the intended recipient (or have received this e-mail
> in error) please notify the sender immediately and delete this e-
> mail. Any unauthorized copying, disclosure or distribution of the
> material in this e-mail is strictly forbidden.
>
> Please refer to http://www.db.com/en/content/eu_disclosures.htm for
> additional EU corporate and regulatory disclosures.
>
> _______________________________________________
> 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

---

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures.


Back to the top