Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-dev] Caching weaved classes

Well it is the org.aspectj.lang.annotation.Aspect annotation, but yes, checking for that will tell you if it is an aspect (even for code style).

cheers,
Andy.

2009/1/25 Simone Gianni <simoneg@xxxxxxxxxx>
Hi Andy,
it's fun how you understand what I want to do even if I haven't written it :) Yes, you got the point, and gave me the right informations (as always). Thanks for your long answer.

I'm pretty sure time is spent inside LTW because if I weave everything at build time and fire up the same application it takes around 5 seconds to start. I profiled it to have confirmation.

Anyway I'm working on a caching classloader, that will cache everything on disk and purge only classes that are changed, as long as an aspect has not been changed, in which case it will clean the cache completely. Obviously, "changed" means the class has changed, including white space change (inside a string :) ) unfortunately. But still, for the 90% of application restarts that does not involve changing an aspect, that should be enough.

Preliminary results are already encouraging, thought still need to know if a certain changed class is an aspect or not, checking for org.aspectj.weaver.Aspect annotation is enough?

Simone

Andy Clement wrote:
Hi Simone,

> reduce load time, which in fact is a bit long being more than 30 seconds for each cycle
> even for a basic project

Have you profiled it to confirm it is the load-time weaver that is to blame here?  Do you
know precisely where the time is spent? It may be a bug.

> But since recently version 1.6.3 focused
> on separating matching from weaving, and since the matching part is
> obviously the first part that the WeavingAdaptor computes upon startup, the
> idea kept on coming up.

Although 1.6.3 introduced a notion of just standalone matching - the weaver itself
was not rewritten to exploit the split down at the lowest level since there it still
makes sense to have these two activities coupled.  Effectively we just provided
another route to the matching logic where you didn't need to provide a bytecode
representation, you could provide anything you like (eg. JDT source ASTs) as
long as it would sit neatly under the AspectJ type abstraction layer.

The weavingadaptor does do some matching, but only the trivial stuff by comparing
types to the include/exclude patterns - it still defers all proper pointcut
matching to the weaver and it doesn't know anything about which types were
affected by which other types.  None of that information is preserved for ltw.

It isn't quite clear to me what you want to do - am I reading it that you want
to probably only reweave things that need reweaving based on aspect changes?
This is what the incremental AspectJ compiler does and it isn't trivial - there is
a whole bunch of state preserved between compiles about what types reference
what types.  Reworking that state so that it can be exploited by load-time dynamic
reweaving wouldn't be a simple bit of work - but is that what you are talking about
wanting to do?  Even then the AspectJ incremental compiler is far from cutting edge
in its analysis - really it only avoids full builds/reweaves for white space changes
and non-structural changes, if you change a pointcut it will kick off a reweave of
everything as it doesn't incrementally work out that you're only now matching
one more join point.

Andy.

2009/1/22 Simone Gianni <simoneg@xxxxxxxxxx <mailto:simoneg@xxxxxxxxxx>>:

> Hi all,
> in the Apache Magma Lab, we're using LTW for our users development
> environment. Lately I rewrote this part to proper pipeline class loading,
> AspectJ weaving and OpenJPA enhancing. While rewriting it, I kept on
> thinking on LTW classes caching performed by Equinox Aspects to reduce load
> time, which in fact is a bit long being more than 30 seconds for each cycle
> even for a basic project. Actually, OSGI has the advantage of knowing which
> bundle weaves which other bundles, and simply trigger a reload of those
> bundles if an aspect has changed. But since recently version 1.6.3 focused
> on separating matching from weaving, and since the matching part is
> obviously the first part that the WeavingAdaptor computes upon startup, the
> idea kept on coming up.
>
> Do you have any pointers for me to start? Do you think it's possible? Do you
> think it's useful?
>
> Simone
>
> --
> Simone Gianni            CEO Semeru s.r.l.           Apache Committer
> http://www.simonegianni.it/
>
> _______________________________________________
> aspectj-dev mailing list
> aspectj-dev@xxxxxxxxxxx <mailto:aspectj-dev@xxxxxxxxxxx> ------------------------------------------------------------------------


_______________________________________________
aspectj-dev mailing list
aspectj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-dev
 


--
Simone Gianni            CEO Semeru s.r.l.           Apache Committer
http://www.simonegianni.it/

_______________________________________________
aspectj-dev mailing list
aspectj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-dev


Back to the top