Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [aspectj-dev] Load-Time Weaving Optimization Update

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




Back to the top