Community
Participate
Working Groups
The attached patches provide the ability to hollow out BCEL objects and to evict them from the BCEL class repository. This has been a significant help in larger scale tests, and I measured this one patch as reducing the heap size from 72 MB to 39 MB when weaving the Glassbox Inspector into a Tomcat with the Spring Petclinic (i.e., a > 100% reduction in overhead). These 3 patches should provide BCEL hollowing and integrate it in with the load-time weaving world. The way that the CLWA calls into the world and how it works is based on a more advanced state sharing model that I will submit in a subsequent patch after this one is integrated (the shared state is really important for load-time weaving with lightweight child classloaders like for JSP's). It would be nice to have a more systematic load-time weaving test suite. The tests I've run so far work properly, modulo many Java 1.4/5 configuration issues: I have noticed that some of the existing load-time weaving tests in Eclipse fail (even for the simple LTW world) because the environment is inconsistent: the Java 5 specific projects aren't on the classpath, and yet the LTWWorld is running in a Java 5 mode, requiring it to use, e.g., Java 5 reflection delegates.
Created attachment 35288 [details] BCEL Delegate Hollowing patch for Weaver module This also contains a useful enhancement that lets us evict woven types once we have finished weaving, if they aren't loaded while loading aspects: it overrides isExpendable. It also fixes a possible bug whereby non-rewoven aspects are deemed expendable
Created attachment 35289 [details] BCEL Delegate Hollowing patch for Loadtime module Small module patch to the loadtime module. Adds lifecycle calls into LTWWorld to record when aspects are being loaded or not (they are never expendable), and to record the start & stop of weaving types (an optimization hint).
Created attachment 35290 [details] Trivial patch to org.aspectj.ajdt.core for bcel delegate hollowing. Implements a new required method, evictReweavingState for Eclipse reference delegates (a no-op).
Created attachment 35292 [details] BCEL Delegate Hollowing patch for Weaver module Includes a change to not evict Object that was added to BcelWorld after I wrote the LTWWorld code.
I've integrated my slightly extended version of Rons eviction code that also deals with fields (and corrected some problems it had with ensuring annotations were fully unpacked). I've wired up eviction to a lifecycle method 'weavingCompleted()' that can be called at the end of weaving (duh...) - this is called from LTWWorld and from regular weaving, however we cannot perform the eviction currently if an incremental compile will follow because of the reset logic in the delegate. I would like to remove this restriction - given what reset does, it really doesn't need the full delegate to remain around, however for now I've just told it not to evict if an incremental compile may follow. This means for LTW, command line or non-incremental ANT building we will evict the delegates. If you compile with -XnoInline then we will also perform the eviction for aspects. We cannot currently evict aspects if you are doing inlining as we have to have a source for the instructions we are going to copy into target classes that match the advice. I've rewritten BcelObjectType to shrink it by switching to bitflags from big boolean flags - could probably do more of this too. I made the Bcel repository javaclass' a weakhashmap rather than a hashmap - I'd like to go further and avoid having different mechanisms (repository or classpathmanager) depending on whether you are LTWing or normal weaving. This is clearly not everything Ron proposed but it's a nice piece of it. I will look at more of it when I get a chance, I've just had to fight the crisis of AJDT interproject compilation getting broken this week. I've also stopped the tests failing. I've changed a lot of stuff this week for this enhancement and for memory usage - I need to rerun the spring LTWing test I have and see what difference these changes make to memory occupation.
types that can later be recovered are now entirely evicted post weave (in 1.6.8) - that seems to address all memory problems. Hollowing out the objects proved costly and throwing them away entirely is working out much better.
