Possible class loader related optimization

[Alan Bateman]

On 03/08/2012 15:11, Eric Caspole wrote:
> Hi Alan,
> What do you mean, "no guarantee that the cached reference will be as 
> expected" ?
>
> The cache will be permanently invalidated and fall back to the normal 
> path if a second loader is seen in defineClass. Since the thread about 
> to do JVM_LatestUserDefinedLoader will not immediately be loading any 
> classes, there is no race with defineClass on another thread as far as 
> I can see. It will either use the cached loader which must be correct 
> for the thread doing the call, or fall back to do the current thing.
>
> Making this work with the various JDK internal loaders is the tricky 
> part, but I hope it is not impossible.
Suppose you've got two threads deserializing at the same time and they 
are running code loaded by different custom loaders. It looks to me that 
one could pick up a loader of code of the other unless there happens to 
be a defineClass to invalidate the cache.

At this time I think the best solution is to override resolveClass, 
assuming the deserialization is under control of the application.

-Alan