Possible class loader related optimization

[Alan Bateman]

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.