Re: [equinox-dev] Integrating AspectJ Load-TimeWeaving into OSGi/Eclipse

[Matthew Webster <matthew_webster@xxxxxxxxxx>]

There are a number of ways to optimize the weaving process:
1. Only instantiate a weaver for bundles that are to be woven. With both
the opt-in and co-opt AOSGi models it is possible to determine whether a
bundle is to be woven based on the visibility of aop.xml files and the
aspects they declare. If there are no aspects defined for a bundle the
weaver is not created.
2. Only instantiate a weaver when weaving is needed. If a byte-code caching
service is available it should be possible to load previously woven bytes
without creating the weaver. Only when a class not previously loaded needs
to be woven or when the set of aspects changes is the weaver actually
created.
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.

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
intelligent!

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.

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
       <equinox-dev@xxxxxxxxxxx>

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


Hi,

>> - 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.
A
> and B may both see some package P but may see completely different
version
> 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
this
> 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?

-Martin


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