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

["Martin Lippert" <lippert@xxxxxxx>]

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