Possible class loader related optimization

[Eric Caspole]

Hi Alan,
I think you might misunderstand the intent of what this webrev is  
doing. What I would like to do is for simple apps that are not making  
use of class loaders, and only run in the default sun.misc.Launcher 
$AppClassLoader, there should not be a need to do a lookup because  
there is only 1 loader in play, not counting ext or reflection  
loaders for the moment.

This is not a per thread cache, it is one global cache. If the app  
uses a second loader and loads a class with it, the cache would be  
shut off because you definitely need to do the lookup if there is  
more than 1 loader.

The JDK internal loaders like the ext loader and reflection make this  
a little complicated, but since they are internal to the JDK I hope  
they can be dealt with and still make this work. But I would need  
some advice from you all on that.
Regards,
Eric

On Aug 3, 2012, at 11:13 AM, Alan Bateman wrote:

> 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
>
>
>