Re: [aspectj-dev] Load-Time Weaving Optimization Update

[Adrian Colyer <adrian.colyer@xxxxxxxxx>]

Seems like the thing to do here is to create a branch in the AspectJ
tree so that we can start experimenting with some of these options
whilst closing out 1.5.0. I'll create a release branch for 1.5.0
(which can then be used for post-release maintenance if we need to
back-port fixes) and that will open up HEAD for 1.5.1 work.

I'll post back once the branch is created.

-- Adrian.

On 15/12/05, Ron Bodkin <rbodkin@xxxxxxxxxxxxxx> wrote:
> I forgot a 5th big improvement: sharing BCEL objects when loading aspect
> definitions. In this case, it's typically a small amount of extra load time
> for a significant compression in memory footprint.
>
> -----Original Message-----
> From: aspectj-dev-bounces@xxxxxxxxxxx
> [mailto:aspectj-dev-bounces@xxxxxxxxxxx] On Behalf Of Ron Bodkin
> Sent: Thursday, December 15, 2005 12:04 AM
> To: 'AspectJ developer discussions'
> Subject: [aspectj-dev] Load-Time Weaving Optimization Update
>
> Hi All,
>
> I wanted to update you on the progress I've been making on tuning load-time
> weaving performance for AspectJ 5, working with Matthew, Alex, Adrian, and
> Andy. I've been focused on dramatically reducing memory requirements while
> preserving decent performance and finding opportunities to improve the same.
>
> To that end, I've created an experimental version of load-time weaving that
> is running almost as quickly as the code in RC1 but that is using
> dramatically less memory.  It works properly for a few different
> configurations that I've tried.
>
> I've attached memory snapshots of loading the Glassbox Inspector on a larger
> configuration (4 web apps) on start up. The RC1 codebase uses -
> Memory_RC1_4apps.html (62 million bytes of heap overhead: 300% total) and
> the use in my optimized version - Memory_Tuned_4apps.html (6 million bytes
> of overhead: 25% total), which loads within 5-10% of the same time. My
> optimized code also handles small classloaders in a reasonable fashion (like
> Tomcat's Jasper loader for JSP's) by allowing sharing BCEL loaded by loading
> aspects.
>
> To optimize the weaving time for my version I avoided making any extraneous
> calls to ClassLoader.getResource. The performance cost for that (at least on
> Windoze) is far too high to justify the sharing gains, IMHO. To a first
> order, time spent weaving is time spent opening and reading files. I think
> it's a lot better to manage a cache of files than to try to allow sharing
> (at least unless you have a participating ClassLoader: see below). Thus far,
> however, a fully aggressive eviction strategy is still performing quite well
> in terms of elapsed and CPU time required.
>
> The major improvements I've made that aren't yet in HEAD are:
> 1. Allowing using of reflection delegates only for bootstrap types (as
> Matthew first suggested to me). Experimentally, a lot of types and a lot of
> types that result in cascading loads come from rt.jar types.
>  2. Using weak references for values in the expendible type maps. This
> allows GC'ing them, which is a major benefit. If starting up in a
> constrained memory environment, this might trade off performance for memory
> use (although it would be better than crashing with an out of memory
> condition). One case I've thought a bit about is whether the expendible maps
> are inadvertently holding references to
> 3. Evicting BCEL objects when finished with all weaving on the stack (for a
> thread). This is a very aggressive memory conservation policy, but so far it
> seems to work quite well.
> 4. Evicting unneeded BCEL information from retained types (i.e., caching
> information needed from the JavaClass and Method data, to allow null'ing
> them out for GC'ing). I now have this working.
>
> While each of these gives a significant benefit, I think they each need to
> be deferred until 1.5.1, since they are too destabilizing at this point at
> the release cycle (and I'm sure I'm not the only one who feels this way).
>
> Two additional minor enhancements I've made are worth considering for 1.5.0:
> 1. Disabling adaptors where no aspects are defined (this is useful if you
> have excluded all aspects from a parent in a child classloader!)
> 2. Avoiding BCEL loading when doing fast matches with NO slow matches
> defined (a useful optimization that can be facilitated by writing aop.xml
> files thoughtfully)
>
> Matthew and Alex, it would be great to talk again to review what I've done
> since we last spoke, and to discuss and plan testing and integration.
>
> Going forward, I think it would be useful to allow a range of caching
> options from evicting immediately (what my version does) to never (what's in
> HEAD). I think load-time weaving will need a range of memory management
> options just as JVM's do.
>
> I also have some thoughts about Matthew's suggestion of using a custom
> interface for ClassLoaders (and an aspect to add these and ITD's to many
> cases). This should allow better performance in the case where we are
> reloading. However, I think this should be a lower priority than effective
> cache management and eviction.
>
> Cheers,
> Ron
>
> Ron Bodkin
> Chief Technology Officer
> New Aspects of Software
> w: (415) 824-4690
>
>
> _______________________________________________
> aspectj-dev mailing list
> aspectj-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-dev
>


--
-- Adrian
adrian.colyer@xxxxxxxxx