> 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
