Re: [aspectj-users] Memory consumption problems

["Ken Horn" <ken.horn@xxxxxxxxxxx>]

 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.

 Is it possible to share the aspect code and/or the pointcuts? Basic
 timers for a cflow is it? ie recording the duration of the flow? Do
 you discard all state from each flow? ie only logging to disk or
 keeping stats? One gotcha might be holding a reference to
 thisJoinPoint or similar, not sure of what the object reference graph
 would look like from those instances?

Can you count the cflows and correlate? The obvious thing, I suppose
 is to make a known number of calls and/or mutliple snapshots.

Could the number of instances be based on the number of classes
accessed in some way? As far as I can remember from the days of
being able to get ajc to spit out java code rather than bytecode, per
cflow was just based on a ThreadLocal -- which begs the question of
how are threads handled in your app.

> On Fri, Jul 25, 2008 at 4:08 PM, Ashley Williams <ashley.williams@xxxxxx> wrote:
>>
>> The figures give no indication as to how steady the memory consumption is
>> since it was just
>> a snapshot: the worry is that it will get a lot worse after weeks in
>> production.
>>
>> I have no idea how aspectj works under the hood and I can't find much info
>> through google either.
>> 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.
>> 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.
>>
>> 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.
>>
>> Maybe there is a page and I just haven't found it yet!
>>
>> aspectj-users-bounces@xxxxxxxxxxx wrote on 25/07/2008 15:28:43:
>>
>>> Ashley, from your numbers the memory consumption seems to be pretty
>>> steady, actually, doesn't it? It certainly isn't growing. so maybe you
>>> should use a profiler to figure out where the memory is actually
>>> consumed. It might just be due to a bug in your implementation. In
>>> general I am very sure that your assumptions about percflow are
>>> correct.
>>>
>>> It may also depend on how you measure memory consumption. Up until now
>>> I have found no really reliable way to measure memory consumption in
>>> Java, even if you manually call the garbage collector etc.
>>>
>>> Eric
>>>
>>> 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
>>> >
>>> >
>>>
>>>
>>>
>>> --
>>> Eric Bodden
>>> Sable Research Group
>>> McGill University, Montréal, Canada
>>> _______________________________________________
>>> 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.
>>
>> _______________________________________________
>> aspectj-users mailing list
>> aspectj-users@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>>
>>
>
>