> It seems that all classes from classloader are cached this way,
> probably at the moment of processing first class from that loader.
The dependencies will be cached, and used for resolution or references
during the weaving of the main type you passed in. But when you pass in the
bytes for the next type to be woven, we will not use the cached bytes for
that type, we should be using the bytes you passed in for it and the cached
version of all the dependencies (otherwise loadtime weaving just wouldn't
work). Does that not work for you because the dependencies are changed due
to your post weaving extra step?
The typemap is in two pieces, the non expendable area and the expendable
area. Those in the expendable area can be discarded at any time because we
know we can easily recover them (they are held via weak reference, so can
vanish as soon as we stop referring to them). Those in the non-expendable
area are held onto for the duration of a weave but may be ejected via the
map demotion process at the end of the particular weave, if we don't need
them around later. During a particular weave, we compare type objects via
== (deliberately) so two type signatures must map to the same type object
and the map is used for that purpose. If you force the map to be off, the
== will fail due to incompatible objects (representing the same type) and
the whole weave will not function correctly. Clearing the expendable map at
the end of a weave would be OK, and forcing demotion to get entries out of
the fixed type map would be OK too. We don't actively clear it because if
you have free memory, keeping the cache around can speed up subsequent
weaves.
cheers,
Andy
On 26 January 2013 04:43, Irek M <iir...@gmail.com> wrote:
> > I just had a quick look and I see the 'bytes'
> > fed into Aj.preprocess by the classpreprocessor and those are the bytes
> that
> > are changed and you are returned the modified version. I'm not really
> sure
> > what passing in null for the bytes means.
>
> Normally it should mean NullPointerException, which would assure me
> that bytes are being read. No null pointer, code just works normally.
> The problem is probably in method
> public BcelObjectType
> org.aspectj.weaver.bcel.BcelWorld.addSourceObjectType(String
> classname, byte[] bytes, boolean artificial)
>
> It has code:
> // ...
> ResolvedType fromTheMap = typeMap.get(signature);
> // now some checking of fromTheMap
> ReferenceType nameTypeX = (ReferenceType) fromTheMap;
> if (nameTypeX == null) {
> // loads nameTypeX from bytes parameter
> } else {
> // uses cached nameTypeX
> }
>
> Unfortunately, disabling typeMap by replacing typeMap.get(signature)
> with null, or setting World.TypeMap.useExpendableMap to false causes
> AspectJ to stop weaving any classes.
>
> > I don't know why your
> > pre-modified bytes aren't being processed by the weaver. Does it only
> happen
> > for the second class loaded this way (and you are seeing something
> hanging
> > around from the first weave) or does it also happen for the first class?
>
> It seems that all classes from classloader are cached this way,
> probably at the moment of processing first class from that loader.
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>
_______________________________________________
aspectj-users mailing list
aspectj-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/aspectj-users
