[aspectj-dev] Fw: Memory Usage for LTW?

[Matthew Webster <matthew_webster@xxxxxxxxxx>]

Alex,

Ron and I have done some successful
hacking today at OOPSLA. We have reused the new ReflectionBasedReferenceTypeDelegate
to resolve types in the BcelWorld using Class.forName() instead of ClassLoader.getResourceAsStream().
We could only use the boot class loader for resolution because of nasty
web application class loaders in Tomcat (that don't delegate) so could
only optimize for system classes e.g. java.lang.String. Also ReflectionBasedReferenceTypeDelegate
or ReflectionBasedReferenceTypeDelegateTest will need tweaking to cope
with method arguments or return types that are arrays (try using java.lang.Class
instead of java.lang.Object in ReflectionBasedReferenceTypeDelegateTest).
However even this limited optimization caused reduced memory usage although
Ron will have to confirm by how much. 

Trying to drop bytecode for woven classes
is problematic because currently we cannot be sure when a class has been
defined (and safely call Class.forName()) and we cannot reload. If we controlled
the class loader rather than using an agent we could use a call back. However
in most situations this is not the case

I don't think we can or should share
state between worlds. This means trying to duplicate the relationships
between the corresponding class loaders which, especially in the case of
pesky web application loaders or non-hierarchical OSGi, are not transparent.
There may also be locking and concurrency issues.

Matthew Webster
AOSD Project
Java Technology Centre, MP146
IBM Hursley Park, Winchester,  SO21 2JN, England
Telephone: +44 196 2816139 (external) 246139 (internal) 
Email: Matthew Webster/UK/IBM @ IBMGB, matthew_webster@xxxxxxxxxx
http://w3.hursley.ibm.com/~websterm/
----------------------
Forwarded by Matthew Webster/UK/IBM on 18/10/2005 01:10 ---------------------------

To:        Matthew Webster/UK/IBM@IBMGB
cc:        
Subject:        FW: Memory Usage for LTW?




-----Original Message-----
From: Alexandre Vasseur [mailto:avasseur@xxxxxxxxx]
Sent: Monday, October 17, 2005 11:03 AM
To: Ron Bodkin
Subject: Re: Memory Usage for LTW?

Yes this is indeed likely to be the most important issue in AJ LTW.The whole
weaver was not designed for LTW and as such keeps quite alot of stuff around
- without beeing as lazy as it could I think.BCEL indeed adds to the picture
as its meta representation of typesetc is quite big. This is not evicted.
Sam Pullara talked about thoseissues during AOSD 2005 based on integration
he did with WLS 8 a whileago (he forced eviction, which further slow down
the weaving and haveunknown side effect on f.e. inlining, reweavable and ITD
I think).
One way to do it would be perhaps to turn BCEL things into reflectthings
once we know the class as actually been loaded - this wouldthus free some
memory. That said the current architecture does notseems to allow for hybrid
world. We had this concept in AW though wedid not had eviction (but I think
I had it in my head thru some threadin the background polling for loaded
class, or thru some other hookand doing the switch).
Another way would be to avoid duplication and promote sharing acrossthe
worlds. We did that in AW. I think each CL gets its own Worldright now,
which means duplicate for representing Object, etc (andgiven one JSP = one
CL it's likely to be bad - to be confirmed).
One thing I have heard from Matthew Webster is also that the metainformation
on aspects (pointcut node information, mungers for adviceetc) is quite big
as well.
If you spot any "easier" optimisation we could implement before finalplease
report them. Else I think it will take some time for the LTW tomature and be
really efficient. Also often it will be a speed vs spacetradeoff.Alex
On 10/15/05, Ron Bodkin <rbodkin@xxxxxxxxxxxxxx> wrote:>>> Hi Alex,>>>> I am
wondering about the memory usage of load-time woven apps.>>>> Case A:>> For
example, if I weave into Tomcat 5.5.9 with a few apps installed using> the
Glassbox inspector (which applies a few aspects), the Java process grows> to
use 150 MB on startup (obviously a crude measurement).>>>> If I don't weave
into the container but just the Web apps, it grows to 145> MB.>>>> If I
weave into the apps only with a null aop.xml file (i.e., not glassbox,> but
an aop.xml file in which no aspects are defined at all), then the memory>
use is 113 MB.>>>> If I don't use a -javaagent, then it uses about 95
MB.>>>> Case B:>> When I previously measured steady state memory usage under
load for the> Glassbox product (somewhat different), I found that the woven
version with> the product used 230MB at steady state when disabled (so it
was not> collecting any data in memory), whereas Tomcat without the java
agent under> similar load was using 110 MB.>>>> I