Possible class loader related optimization

[Alan Bateman]

On 03/08/2012 16:45, Eric Caspole wrote:
> Hi Alan,
> I think you might misunderstand the intent of what this webrev is 
> doing. What I would like to do is for simple apps that are not making 
> use of class loaders, and only run in the default 
> sun.misc.Launcher$AppClassLoader, there should not be a need to do a 
> lookup because there is only 1 loader in play, not counting ext or 
> reflection loaders for the moment.
>
> This is not a per thread cache, it is one global cache. If the app 
> uses a second loader and loads a class with it, the cache would be 
> shut off because you definitely need to do the lookup if there is more 
> than 1 loader.
>
> The JDK internal loaders like the ext loader and reflection make this 
> a little complicated, but since they are internal to the JDK I hope 
> they can be dealt with and still make this work. But I would need some 
> advice from you all on that.
I think I understand the proposal, I'm just saying that 
+UsePrimordialLoaderCache would lead to correctness issues (like maybe 
using the wrong defining loader) for more complicated cases that the 
changes are intended for.

I think the only way currently to help the performance here is to extend 
ObjectInputStream and override the resolveClass method.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20120803/ab37df11/attachment.html