RFR 6642881: Improve performance of Class.getClassLoader()

Mandy Chung mandy.chung at oracle.com
Thu Jun 19 20:34:17 UTC 2014


On 6/19/14 12:34 PM, Joel Borggrén-Franck wrote:
> Hi,
>
> On 19 jun 2014, at 20:46, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
>> On 6/17/14, 12:38 AM, Joel Borggrén-Franck wrote:
>>> Have you considered hiding the Class.classLoader field from reflection? I’m not sure it is necessary but I’m not to keen on the idea of people poking at this field with Unsafe (which should go away in 9 but …).
>> I don't know how to hide the field from reflection.  It's a private final field so you need to get priviledges to make it setAccessible.  If you mean injecting it on the JVM side, the reason for this change is so that the JIT compilers can inline this call and not have to call into the JVM to get the class loader.
>>
> There is sun.reflect.Reflection.registerFieldsToFilter() that hides a field from being found using reflection. It might very well be the case that private and final is enough, I haven’t thought this through 100%. On the other hand, is there a reason to give users access through the field instead of having to use Class.getClassLoader()?
>
There are many getter methods that returns a private final field.
I'm not sure if hiding the field is necessary nor a good precedence
to set. Accessing a private field requires "accessDeclaredMember"
permission although it's a different security check (vs "getClassLoader"
permission).  Arguably before this new classLoader field, one could
call Class.getClassLoader0() via reflection to get a hold of class
loader.

Perhaps you are concerned that the "accessDeclaredMember" permission
is too coarse-grained?  I think the security team is looking into
the improvement in that regards.

Mandy



More information about the jdk9-dev mailing list