[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] Integrating AspectJ Load-TimeWeaving into OSGi/Eclipse

Hi Matthew,

There are a number of ways to optimize the weaving process:
1. Only instantiate a weaver for bundles that are to be woven...
2. Only instantiate a weaver when weaving is needed...

Agree, but is the pure creation of a weaver already a performance or memory footprint problem (if the weaver never starts to weave)?

3. Reduce the footprint of the weaver. While every bundle has a class
loader, every class loader creates a weaver and every weaver needs a world
to resolve types it should be possible to reduce the dependence on
byte-code and allow data to be garbage collected and reloaded if necessary.
There are already a number of such performance features in the weaver and
more are planned.

Great to hear that more improvements are planned for the AspectJ weaver. What do you think about letting different weavers share their data (with respect to the bundle dependencies) to reduce the memory footprint even more?

Ideally any caching service should not rely on explicit user definition of
a change e.g. plug-in version. This might be OK in a deployed environment
but doesn't work in a development environment where classes and aspects are
constantly being changed. Furthermore our work has shown that a caching
service needs to not only be aware of changes to the bundle being woven and
any visible aspects but also required types in other bundles. For example a
change to a type in one bundle can affect whether a sub-type in another
bundle is woven and hence whether a cached version of the byte-code is now
invalid. A caching service must either be very conservative or very

I would vote for the conservative one at the beginning... ;-) Do you have any idea how to let the caching service detect changes if not done via the version number, for example? I thought about some kind of hashing but that seems to impact performance in a negative way. And performance is a very critical factor for LTW I think...

We have modified the AOSGi PoC so that the enhanced adaptor declares
Weaving and Caching service interfaces. It then looks for implementers of
these services each time it creates a class loader. This enables at least 4
different OSGi environments to be used: vanilla, just weaving, just caching
or caching and weaving.

Sounds cool. Do you have the code of AOSGi available somewhere? Is it open source? I would love to take a look at it...


Matthew Webster AOSD Project Java Technology Centre, MP146 IBM Hursley Park, Winchester, SO21 2JN, England Telephone: +44 196 2816139 (external) 246139 (internal) Email: Matthew Webster/UK/IBM @ IBMGB, matthew_webster@xxxxxxxxxx http://w3.hursley.ibm.com/~websterm/

"Martin Lippert" <lippert@xxxxxxx>@eclipse.org on 21/09/2005 12:20:57

Please respond to Equinox development mailing list

Sent by:    equinox-dev-bounces@xxxxxxxxxxx

To: "Equinox development mailing list" <equinox-dev@xxxxxxxxxxx> cc: Subject: Re: [equinox-dev] Integrating AspectJ Load-TimeWeaving into OSGi/Eclipse


- AJEER creates separate weaver instances for each bundle. This is done
to ensure that the type resolution for the weaver matches exactly the
class loading of the bundle.
Interesting point. The view of the world differs from bundle to bundle.
and B may both see some package P but may see completely different
of it.  From your comment hten I assume that the weaver somehow has a
cache or view of the types in a system such that having just one weaver
would result in flat namespace?

Yes. Each weaver has a "world" which is responsible for resolving type information that are used by the weaver. Therefore the weaver world parses the bytecode of classes that are requested by the weaver.

In AJEER each bundle has its own weaver (and world). This means also that
each weaver resolves all types that it needs. If the same type is
requested by another weaver instance that instance would reparse the same
type. So maybe a delegation model between weavers (so charge common types)
would be useful here.

(Note that "resolve types" does not mean the normal class loading.)

What are the performance implications of having multiple weavers?  Like
say I was to have 2000 of them?  Do they stick around or are the created
serially as each bundle is woven?

This is a very interesting point from my point of view. The weaver instances are created once for each bundle and remain in the VM as long as the bundle is resolved (because class loading for the bundle can happen at any time).

This implicates that the resolved type information of the weaver world
remain in the VM (current AspectJ implementation, I think). Maybe an
improved version of the weaver world could allow those type informations
to be garbage collected and re-parsed if necessary???

- AJEER implements a byte-code caching mechanism to skip the
time-consuming weaving task if nothing has changed (same bundle version,
same aspect version, same set of aspects).
Cool.  any idea how this might play with a VM based shared classes
mechanism?  On a different point, do you also have to know about changes
in supporting classes (e.g., supertypes) and classes from fragments?

No idea at the moment... Never thought about the VM mechanisms for shared classes... And the second point is interesting, too. Hm.....

Therefore AJEER is separated into two bundles: the first one enhances
the OSGi framework adaptor to intercept class loading and takes care of
the byte-code cache. It provides a hook for other bundles to inject
bytecode modifier components. The second bundle injects the AspectJ
weaver as a bytecode modifier component.
So is the adaptor would be one point of overlap between the two
approaches?  Would it make sense to try and reconcile/unify that hook as
first step?  Seems that such a mechanism should be generic.  Exploring
this is interesting as we are wanting to refactor the adpator to make
kind of change independent of, for example, the disk layout, which also
happens to be defined by adaptors but is clearly not interesting here.

Agree, such an adaptor would be a nice starting point. It should allow other bundles to inject the modification functionality and could handle additional dynamic dependencies between bundles.

I would be able to inject the AJEER model into such an adaptor. What about
the AOSGi implementation?


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

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