Possible class loader related optimization

[Karen Kinnear]

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

On Jul 20, 2012, at 3:32 PM, Eric Caspole wrote:

> Hello JVM team,
> 
> While running a customer app that frequently uses ObjectInputStream, we noticed a lot of time spent in JVM_LatestUserDefinedLoader and some related methods like vframeStreamCommon::skip_reflection_related_frames. When doing ObjectInputStream.read(), it needs to find the class loader that goes with the user application call site to get the class of the freshly read object. This operation walks down the stack on the thread looking at the nmethod's classes to find the owner class's loader.
> 
> But it appears this application, like probably a great many real world applications out there, uses only one class loader, the primordial sun.misc.Launcher$AppClassLoader.
> 
> I think if there is only one user class loader in play, we should be able to cache it and avoid the stack walk. More complicated cases like web app servers, where often each web app is run in its own loader, might still require the stack walk lookup.
> 
> I have made a webrev where I cache a ref to the primordial sun.misc.Launcher$AppClassLoader and use the cached value for these JVM_LatestUserDefinedLoader lookups, and flush the cache and force a normal stack walk lookup if a new user class loader comes into play.
> Since our application only uses the primordial loader, this optimization was effective and sped it up a few percent.
> 
> My webrev is at: http://cr.openjdk.java.net/~ecaspole/latestloader/webrev/
> 
> I attached here a small test case using ObjectInputStream that shows this use case.
> 
> Please let me know your comments. I know there are a lot of special purpose class loaders used internally in the JDK but I think most of them never run code that will arrive at ObjectInputStream.read().
> 
> Regards,
> Eric
> <StreamChicken.java><Chicken.java>