[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [equinox-dev] Integrating AspectJ Load-TimeWeaving into OSGi/Eclipse
|
Martin,
>Agree, but is the pure creation of a weaver already a performance or
>memory footprint problem (if the weaver never starts to weave)?
We need to do some measurements in this area.
>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?
Rather than create a parallel network of weavers the plan is to use
java.lang.Class objects and reflection for certain resolved types instead
of bytecode.
>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...
I had and enlightening conversation with Jeff yesterday which has set my
plans in this area back to square one :-(.
>Sounds cool. Do you have the code of AOSGi available somewhere? Is it
>open source? I would love to take a look at it...
Jeff has suggested creating an Equinox incubation area where we can share
our implementations and work on convergence.
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 26/09/2005 23:19:15
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 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
> intelligent!
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...
-Martin
>
> 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
>
>
> _______________________________________________
> 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
