Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-dev] Some questions about load-time weaving

Hi Eric,

in addition to Matthews answers some comments from my side:

Well this seems a bit outdated now, since version 1.2 is out and
maybe some things have changed - maybe not, I don't know. So is there
any real experience already with the provided load-time weaving
implementation of 1.2?

I have integrated the weaving functionality of AspectJ 1.2 into a specialized Eclipse runtime. This runtime lets you put aspects into Eclipse plugins. The weaving runtime uses load-time weaving to weave those aspects into the whole system.

Using this load-time weaving runtime I am running the complete Eclipse IDE on top of it. My largest test case is a monitor aspect that advices nearly everything of Eclipse at load-time. And it works fine!!!

In particular I would like to know:

Are there any decent estimations so far of the performance impacts
inwolved at class loadtime?

The performance of the weaving highly depends on the aspects that are defined. Some experiences:

- load-time weaving for my monitor aspect (as said advices everything of more than 3000 classes at load-time) consumes a lot of time. Startup time of such a system degrades of about a factor of 10 or more. (that is why I am using a special caching strategy for the load-time weaving Eclipse runtime).

- load-time weaving for a single and simple aspect is most effective using "within". In such a case the AspectJ weaving implementation can determine pretty effectively whether a class should be passed to the weaver or not.

I know some people from IBM who are using the weaving Eclipse runtime to implement some CSCW stuff for Eclipse. And they are pretty satisfied with the performance of the load-time weaving runtime in combination with the caching for their use cases.

Another problem is, from my point of view, the footprint of load-time weaving. The weaver part of the compiler implementation of AspectJ 1.2 consumes a lot of memory. And it is extremely difficult to tell the weaver when to trash objects. You never know whether you will need to weave some more classes in tue future or not. Therefore you never know if the weaver has finished its work. That is another reason why I combined that with caching.

Hope that provides some useful information.

Best regards,
-Martin

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature


Back to the top