Bug ID: JDK-8334772 Change Class::signers to an explicit field

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

JDK 24
24 b08Fixed

There are protectionDomain and signers fields currently injected to Class in javaClasses.cpp, so Java code's access to them must go through native. Making them explicit allows easier access via Java code, as long as we note that these fields are also accessed by the JVM.

The protectionDomain field is accessed via native methods in java.security.AccessController, which would be better taken care of by the security team. We can move the signers fields for now.

Note that to move protectionDomain field in the future, there are additional tests to take care of:
1. test/hotspot/gtest/oops/test_instanceKlass.cpp anticipates injected protection_domain field; should be removed.
2. test/jdk/java/lang/reflect/AccessibleObject/ModuleSetAccessibleTest.java and TrySetAccessibleTest anticipates private Class constructors; need to update accordingly.

Changeset: 39f44768 Branch: master Author: Chen Liang <liach@openjdk.org> Date: 2024-07-18 22:22:59 +0000 URL: https://git.openjdk.org/jdk/commit/39f44768131254ee11f723f92e2bac57b0d1ade0
18-07-2024
JVMTI_REFERENCE_SIGNERS would require an update to the JVM TI spec. The compatibility impact is likely very low. HPROF class dump SIGNERS would require an update to the HPROF format. There are several ways this could be done but rev'ing the HPROF is mildly disruptive.
18-07-2024
The JVM shouldn't care at all about signers but unfortunately there's a jvmti tag and heap dump field that exposes it. Can we remove that too in a further patch? // report a class referencing its signers. inline bool CallbackInvoker::report_signers_reference(oop referrer, oop referree) { if (is_basic_heap_walk()) { return invoke_basic_object_reference_callback(JVMTI_REFERENCE_SIGNERS, referrer, referree, -1); } else { return invoke_advanced_object_reference_callback(JVMTI_HEAP_REFERENCE_SIGNERS, referrer, referree, -1); } }
18-07-2024
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/20223 Date: 2024-07-17 19:47:44 +0000
17-07-2024
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/20221 Date: 2024-07-17 17:47:11 +0000
17-07-2024
[~liach] Probably best to check with Colleen on any concerns from the hotspot runtime side, otherwise it's great to see this one getting attention.
16-07-2024

CSR :	JDK-8336676 - Remove native modifier from Class::getSigners method
Duplicate :	JDK-8003551 - Move Signers out to the JDK
Relates :	JDK-8336804 - Drop callback from class to its signers with ref kind JVMTI_HEAP_REFERENCE_SIGNERS
Relates :	JDK-8334394 - Race condition in Class::protectionDomain