RFR: 8165434: [JVMCI] remove uses of setAccessible
Christian Thalinger
cthalinger at twitter.com
Tue Sep 6 18:12:21 UTC 2016
> 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.
src/share/vm/jvmci/vmStructs_jvmci.cpp
declare_constant(JVM_ACC_FIELD_HAS_GENERIC_SIGNATURE) \
+ declare_preprocessor_constant("JVM_ACC_VARARGS", JVM_ACC_VARARGS) \
+ declare_preprocessor_constant("JVM_ACC_BRIDGE", JVM_ACC_BRIDGE) \
+ declare_preprocessor_constant("JVM_ACC_ANNOTATION", JVM_ACC_ANNOTATION) \
+ declare_preprocessor_constant("JVM_ACC_ENUM", JVM_ACC_ENUM) \
declare_preprocessor_constant("JVM_ACC_SYNTHETIC", JVM_ACC_SYNTHETIC) \
Please align the “\”.
Otherwise this looks good and generally a good cleanup.
> https://bugs.openjdk.java.net/browse/JDK-8165434
>
> -Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20160906/7f2fa818/attachment-0001.html>
More information about the hotspot-compiler-dev
mailing list