Skip to main content

[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


Back to the top