> 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.
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