Possible class loader related optimization

[Eric Caspole]

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.
Thanks,
Eric


On Aug 3, 2012, at 9:46 AM, Alan Bateman wrote:

> On 01/08/2012 19:13, Karen Kinnear wrote:
>> Eric,
>>
>> First, I wanted to thank you for doing this investigation, and for  
>> sending both a webrev and test cases. We really appreciate it.
>>
>> In looking over your changes, it is not obvious to me that this  
>> change would always return the same information from
>> JVM_LatestUserDefinedLoader that you would get today. I did not  
>> write any additional test cases, but walking through
>> the source code, it appears to me that there are a couple of  
>> possible cases in which the cached system loader might
>> be returned when the current code would return a different loader,  
>> such as an extension class loader or the null
>> boot loader (what those of us in the vm would call the  
>> "primordial" loader :-) if there were no application loaders on
>> that particular thread's stack.  It is not obvious to me that it  
>> is possible to match the exact current behavior in all cases
>> without actually walking the current stack. Did I read that  
>> correctly?
>>
>> If I misunderstood something, then I did have some more detailed  
>> comments about the implementation, but let's work
>> through ensuring we believe this type of approach is possible first.
>>
>> thanks,
>> Karen
>>
> I don't think the class loader can be cached as proposed as there  
> is no guarantee that the cached reference will be as expected.  
> There have been suggestions in the past to cache it via a thread- 
> local but that isn't always going to be correct either.
>
> For now, all I can suggest is for the application to extend  
> ObjectInputStream and override the resolveClass method.
>
> -Alan.
>