[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [aspectj-dev] Re: [Bug 55107] add removeLibraryAspect method to weaver
- From: Martin Lippert <lippert@xxxxxxx>
- Date: Wed, 31 Mar 2004 22:56:47 +0200
- Delivered-to: firstname.lastname@example.org
- User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
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?
Description: S/MIME Cryptographic Signature