RFR: 8165434: [JVMCI] remove uses of setAccessible
Doug Simon
doug.simon at oracle.com
Tue Sep 13 22:33:59 UTC 2016
JPRT testing revealed a test bug in FindUniqueConcreteMethodTest.java where CompileToVM.findUniqueConcreteMethod was being called with a default method. This is not supported by HotSpot which is why the only other usage of this private API avoids it:
http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/ec36e3e03d65/src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotResolvedJavaMethodImpl.java#l385
The offending test in FindUniqueConcreteMethodTest has been commented out.
-Doug
> On 08 Sep 2016, at 15:12, Doug Simon <doug.simon at oracle.com> wrote:
>
>>
>> On 07 Sep 2016, at 19:52, Christian Thalinger <cthalinger at twitter.com> wrote:
>>
>>>
>>> On Sep 7, 2016, at 2:29 AM, Doug Simon <doug.simon at oracle.com> wrote:
>>>
>>>>
>>>> On 06 Sep 2016, at 20:12, Christian Thalinger <cthalinger at twitter.com> wrote:
>>>>
>>>>
>>>>> On Sep 5, 2016, at 6:45 AM, Doug Simon <doug.simon at oracle.com> wrote:
>>>>>
>>>>> JVMCI currently uses java.lang.reflect.AccessibleObject.setAccessible to get at private internals of certain JDK objects (e.g. java.lang.reflect.Method::slot). In light of changes around java.lang.reflect.AccessibleObject::setAccessible at http://openjdk.java.net/jeps/261, this may require extra command line options at some point. To avoid that, I’ve removed all uses of setAccessible in JVMCI.
>>>>>
>>>>> http://cr.openjdk.java.net/~dnsimon/8165434/
>>>>
>>>> src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/ModifiersProvider.java
>>>>
>>>> + int BRIDGE = 0x0040;
>>>> + int VARARGS = 0x0080;
>>>> + int SYNTHETIC = 0x1000;
>>>> + int ANNOTATION = 0x2000;
>>>> + int ENUM = 0x4000;
>>>> I wish we could avoid that. We can’t use this stuff because it’s HotSpot-dependent, right?
>>>> + assert ModifiersProvider.SYNTHETIC == getConstant("JVM_ACC_SYNTHETIC", Integer.class);
>>>> + assert ModifiersProvider.ANNOTATION == getConstant("JVM_ACC_ANNOTATION", Integer.class);
>>>> + assert ModifiersProvider.BRIDGE == getConstant("JVM_ACC_BRIDGE", Integer.class);
>>>> + assert ModifiersProvider.VARARGS == getConstant("JVM_ACC_VARARGS", Integer.class);
>>>> + assert ModifiersProvider.ENUM == getConstant("JVM_ACC_ENUM", Integer.class);
>>>> What if we convert these constants to interface methods and the VM-dependent part has to implement them? Or maybe even keep the fields and assign them via interface methods.
>>>
>>> Following your suggestion, I’ve factored out these VM dependent flags to a new HotSpotModifiers class:
>>>
>>> http://cr.openjdk.java.net/~dnsimon/8165434.v2/
>>
>> Excellent. One question… I noticed HotSpotModifiers is an interface but no other class implements it. Is there a reason for it being an interface?
>
> Nope. It’s now a class.
>
>>
>> Only nit, remove 2011:
>> 2 * Copyright (c) 2011, 2016, Oracle and/or its affiliates. All rights reserved.
>
> Fixed.
>
> -Doug
More information about the hotspot-compiler-dev
mailing list