| Re: [aspectj-dev] Re: [Bug 55107] add removeLibraryAspect method to weaver |
>Ah, interesting. Never thought of which aspect constructs might cause >schema changes to a class. Two interesting new things I picked up at AOSD: >- The guys from the JRockit VM plan to include support for schema >changes for HCR in their next release (could be October this year). This >would make HCR for dynamic aspect weaving a lot easier. >- I talked to Wes about this and he pointed me to an interesting >situation. Assume you have an aspect that works against an interface >(inside a pointcut definition). When changing a class via HCR that now >implements this interface and becomes part of the crosscut (and possibly >all subclasses) all those classes need to be re-woven (same if you >remove the interface). And what would that mean if you limit HCR to >aspect code? It might become quite difficult to figure out which classes >to re-weave and which not. Until all JVMs (in particular Sun) support any change to a class the HCR+AOP will be problematic. HCR is primarily designed for debugging because anything more than localized changes can cause your program to crash. Adding/removing interfaces is certainly something that is not currently supported. >This is not exactly the thing that I am doing right now. If an aspect is >uninstalled from the system, all plugins that are affected by this >aspect (plugins that have loaded classes which were woven with this >aspect at load-time) will be unresolved and re-resolved. That means, >that their complete code will be re-loaded into the VM (all objects are >thrown away, new classloader created, state recreated). I remove the >aspect from the world after the plugin is unresolved and before it is >re-resolved. That means that when the plugin is reloaded, it is reloaded >completely with the new set of aspects (as all other plugins that are >affected by the aspect). Using this mechanism the set of aspects is >completely stable during the lifetime of a plugin. Good. In which case I don't think you need the "removeAspectLibrary()" enhancement. Each BcelWorld and accompanying BcelWeaver should have the lifetime of a single class loader. It cannot be associated with another one. I suspect you rationale for reusing the world and simply changing the set of aspects associated with it stems from the fact that they currently seem quite "heavy". I hope to address this in the longer term for LTW by using run-time rather than byte-code type resolution, something that will be needed to reduce the footprint in large systems with multiple weaving class loaders. Cheers. 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 31/03/2004 21:56:47 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 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. Ah, interesting. Never thought of which aspect constructs might cause schema changes to a class. Two interesting new things I picked up at AOSD: - The guys from the JRockit VM plan to include support for schema changes for HCR in their next release (could be October this year). This would make HCR for dynamic aspect weaving a lot easier. - I talked to Wes about this and he pointed me to an interesting situation. Assume you have an aspect that works against an interface (inside a pointcut definition). When changing a class via HCR that now implements this interface and becomes part of the crosscut (and possibly all subclasses) all those classes need to be re-woven (same if you remove the interface). And what would that mean if you limit HCR to aspect code? It might become quite difficult to figure out which classes to re-weave and which not. >>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. This is not exactly the thing that I am doing right now. If an aspect is uninstalled from the system, all plugins that are affected by this aspect (plugins that have loaded classes which were woven with this aspect at load-time) will be unresolved and re-resolved. That means, that their complete code will be re-loaded into the VM (all objects are thrown away, new classloader created, state recreated). I remove the aspect from the world after the plugin is unresolved and before it is re-resolved. That means that when the plugin is reloaded, it is reloaded completely with the new set of aspects (as all other plugins that are affected by the aspect). Using this mechanism the set of aspects is completely stable during the lifetime of a plugin. This could, of course, mean in the worst case (all plugins are affected) that the complete system (except the runtime itself) has to be reloaded. But if the plugins are well-modularized and you do not want to runtime-deploy "global" aspects this could work pretty fine together this the dynamic features of the Eclipse 3.0 runtime, I think. What do you think? Best regards, Martin
Attachment:
smime.p7s
Description: Binary data