[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




>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