RFR 6642881: Improve performance of Class.getClassLoader()
Coleen Phillimore
coleen.phillimore at oracle.com
Thu Jun 19 18:46:51 UTC 2014
Hi Joel, See below.
On 6/17/14, 12:38 AM, Joel Borggrén-Franck wrote:
> Hi Coleen,
>
> On 16 jun 2014, at 17:42, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
>
>> Summary: Add classLoader to java/lang/Class instance for fast access
>>
>> In order to improve performance of Class.getClassLoader() in a way to allow the compilers to automatically optimize this call, I added the classLoader to the instance of java/lang/Class. For microbenchmarks, this results in a 98% improvement, which was expected. For Oracle internal applications, this results in a 10-12% improvement on solaris/sparc. The increase in size of java/lang/Class can be offset by other changes (removing constant pool lock, or removing signers).
>>
>> See bug link https://bugs.openjdk.java.net/browse/JDK-6642881 and associated linked bugs for more details.
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_hotspot/
>> open webrev at http://cr.openjdk.java.net/~coleenp/6642881_jdk/
>>
>> There is both hotspot and jdk changes for this change. The hotspot changes can work without the jdk changes (check for optional field), but not vice-versa. I'll file another bug (and compatibility request) to remove JVM_GetClassLoader from hotspot.
>>
>> Tested with jck lang, vm, api/java_lang tests with/without jdk change, nsk vm.quick.testlist and hotspot jtreg tests, and jprt.
>>
> 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.
Thanks,
Coleen
>
> Otherwise looks good.
>
> cheers
> /Joel
More information about the jdk9-dev
mailing list