[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [aspectj-dev] Caching weaved classes
|
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>
> https://dev.eclipse.org/mailman/listinfo/aspectj-dev
>
------------------------------------------------------------------------
_______________________________________________
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/
