| 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