Possible class loader related optimization

[Eric Caspole]

On Aug 1, 2012, at 2:13 PM, 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?

Hi Karen,

As I understand it, JVM_LatestUserDefinedLoader will not return the  
null loader, since the JDK will never use this path except on behalf  
of a user application. I am not sure what the ext loader is used for  
besides crypto, such that it might ever arrive to call  
JVM_LatestUserDefinedLoader. Definitely that seems like it might  
complicate the situation, hopefully not so as to make this change  
impractical.

So the overall idea is if the vast majority of the user app is  
running in just 1 loader, can it be cached? In my webrev, I special  
cased the ext loader and the reflection loader since they did not  
affect the correctness in our case. But there is probably a better  
way to do it.

Otherwise, I think this will basically work for other 'real' user  
loaders that are explicitly created and used in the application code.  
In my tests I have a non-delegating URL loader that gets used in  
addition to the sun.misc.Launcher$AppClassLoader and it works to shut  
off the cache and fall back to the regular path when the URL loader  
gets used for the first time.

My special case hacks aside, which are due to the JDK internal  
operation, and probably needs more thought, can you think of a more  
complicated scenario to test? I am trying to think of something with  
static initializer blocks that use object streaming or something like  
that would cause a weird situation.

Thanks for looking this over.
Eric



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