[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-dev] Re: [Bug 55107] add removeLibraryAspect method to weaver




I played with hot code replacement (for various reasons) and there is
one difficulty that I see when talking about runtime weaving for AspectJ
done via HCR: Current VMs do not support "real" changes to the classes
that are replaced.
> You are correct. There is a large subset of dynamic crosscutting that
cone be supported by HCR in current JVMs as long a you avoid
"thisJoinPoint", "around closure" and "staticinitialization" advice. I
discovered this when doing the lint option for serialVersionUID which is
also affected by adding/removing fields and methods.

>So what I am trying is to let my enhanced runtime react
>to those install/uninstall events correctly. This way you can
>install/uninstall aspects at runtime without closing the application and
>have a real "unweaving" at runtime.
But you are not supporting "unweaving" at run-time because you cannot
unweave classes that have already been woven. What you are actually doing,
when you add or remove an aspect to/from your run-time and consequently add
or remove an aspect to/from the world for a particular plug-in, is affect
those classes that don't happen to be loaded yet. What you end up with is a
plug-in for which the cross-cutting set is unknown. This seems dangerous to
me. The set of aspects that are used to weave a plug-in should not change
for the lifetime of that plug-in. If a plug-in is updated at run-time it
can be woven with the latest set of aspects.

>But it seems to work.
You are correct. If you call "prepareForWeave()" after adding/removing an
aspect to/from the world the munger cache in the weaver is refreshed.

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 23/03/2004 17:34:58

Please respond to aspectj-dev@xxxxxxxxxxx

Sent by:    aspectj-dev-admin@xxxxxxxxxxx


To:    aspectj-dev@xxxxxxxxxxx
cc:
Subject:    Re: [aspectj-dev] Re: [Bug 55107] add removeLibraryAspect
       method to weaver



Hi,

> I have moved the discussion to aspectj-dev as the questions are broader
> than the suggested weaver enhancement.
>
>>But I disagree in the run-time weaving scenario.
>
> When you say "run-time" what do you mean. The proposed LTW design for JDK
> 1.4 does not support hot-code-replace as there is no interception point.
> Developers should use normal compile-time weaving with incremental
> compilation and Eclipse should automatically submit all the changed
classes
> and aspects to the JVM being debugged. In 1.5 the java.lang.instrument
API
> provides the opportunity to reweave HRC'd classes. However HCR for
aspects
> is a different proposition which I haven't thought about yet!

Two thoughts that I have in mind:

I played with hot code replacement (for various reasons) and there is
one difficulty that I see when talking about runtime weaving for AspectJ
   done via HCR: Current VMs do not support "real" changes to the classes
that are replaced (doesn't mapper if it is via the debug option of JDK
1.4 or the instrument package of JDK 1.5). Most VMs support only changes
to the implementation of methods. You are not allowed to add or remove
methods or static things (what you would need for AspectJ, I think).
Only few VMs support new or removed methods for redefined classes. If
you start to add fields to a class, I do not know of any VM that
supports this kind of change to a class (even though the theory for this
feature is well-known). Therefore I skipped any experiments to do
run-time weaving for AspectJ using HCR. But I would be happy to hear if
someone else got different results.

What I do instead to play with "run-time-like" weaving for AspectJ is to
enhance my AspectJ-enabled Eclipse Runtime to handle dynamic plugin
behavior correctly. In my current implementation the runtime uses
load-time weaving for plugins to weave existing aspects into the system.
Plugins can define new aspects via an extension point of my enhanced
runtime. When you think about dynamic plugins (as the are supported by
the new OSGi-based runtime of Eclipse 3.0) you could think of plugins
being installed and uninstalled at runtime. The Eclipse runtime handles
this correctly. So what I am trying is to let my enhanced runtime react
to those install/uninstall events correctly. This way you can
install/uninstall aspects at runtime without closing the application and
have a real "unweaving" at runtime. Sounds a bit tricky and I am not
sure whether this will work for all possibilities of the AspectJ
language but let me try. ;-)

Therefore I remove aspects from an existing weaver.

>>BTW 1: How does the incremental compilation deal with deleted aspects?
>
> My understanding is that when an aspect is added, modified or removed
> everything is rewoven thereby preserving the invariant.

Ah, okay. No magic here. ;-)

>>BTW 2: You can achieve the same effect (that the removeLibraryAspect
> method
>>would provide) via World.getCrosscuttingMembersSet().deleteAspect(..).
>
> That method is only called once during BcelWeaving construction. Mutation
> is not supported.

But it seems to work. ;-) Okay, haven't tried too many things with this
stuff. Are there any obvious things were the removal could cause
problems with the internal weaver structures?

-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/
>
>
> bugzilla-daemon@xxxxxxxxxxx on 20/03/2004 14:14:12
>
> To:    Matthew Webster/UK/IBM@IBMGB
> cc:
> Subject:    [Bug 55107] add removeLibraryAspect method to weaver
>
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=55107
>
>
>
>
>
> ------- Additional Comments From lippert@xxxxxxx  2004-03-20 09:14
-------
> I see this from a different point of view. I agree to your objection
> regarding
> the weaving class loader and the typical load-time weaving scenario
> described in
> bug #31460. Therefore you should not remove any aspects while the
load-time
> weaving class loader is active.
> But I disagree in the run-time weaving scenario. Of course you have to be
> careful with already loaded classes, reloading, and so on. But if you
take
> care
> of the different situations and handle then in the right way, the
> removeLibraryAspect method would just prevent you from creating a new
> weaver
> instance.
>
> BTW 1: How does the incremental compilation deal with deleted aspects?
>
> BTW 2: You can achieve the same effect (that the removeLibraryAspect
method
> would provide) via World.getCrosscuttingMembersSet().deleteAspect(..).
>
>
>
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug, or are watching someone who is.
>
>
>
> _______________________________________________
> aspectj-dev mailing list
> aspectj-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/aspectj-dev



Attachment: smime.p7s
Description: Binary data