Re: [aspectj-dev] Caching weaved classes

[Andy Clement <andrew.clement@xxxxxxxxx>]

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>:
> 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
> https://dev.eclipse.org/mailman/listinfo/aspectj-dev
>