Skip to main content
[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 
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: S/MIME Cryptographic Signature

Back to the top