Possible class loader related optimization

[Eric Caspole]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: StreamChicken.java
Type: application/octet-stream
Size: 3856 bytes
Desc: StreamChicken.java
Url : http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20120720/99e73bbf/StreamChicken.java 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Chicken.java
Type: application/octet-stream
Size: 103 bytes
Desc: Chicken.java
Url : http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20120720/99e73bbf/Chicken.java