[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [aspectj-dev] Fw: Memory Usage for LTW?
|
I encountered those array bugs that Matthew and Ron found this week
too whilst doing some Spring integration testing. This should now be
fixed in the tree.
On 18/10/05, Matthew Webster <matthew_webster@xxxxxxxxxx> wrote:
>
> 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
>
>
>
>
> _______________________________________________
> aspectj-dev mailing list
> aspectj-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-dev
>
>
>
--
-- Adrian
adrian.colyer@xxxxxxxxx