RFR 6642881: Improve performance of Class.getClassLoader()

[Coleen Phillimore]

On 6/19/14, 4:34 PM, Mandy Chung wrote:
> 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.

Yes, thank you Mandy.

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