> 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.