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
"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>
Subject: Re: [equinox-dev] Integrating AspectJ Load-TimeWeaving
Interesting point. The view of the world differs from bundle to bundle.
- 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.
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
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 mailing list