On Thu, 18 Jul 2024 13:48:06 GMT, Chen Liang <li...@openjdk.org> wrote:
>> `Class` has 2 VM-injected fields that can be made explicit: `Object[] >> signers` and `ProtectionDomain protectionDomain`. We make the signers field >> explicit. (The ProtectionDomain can be revisited when SecurityManager is >> removed, as SecurityManager is accessing it via JNI as well.) >> >> Migrate the JNI code to Java. The getter previously had a redundant >> primitive type check, which is dropped in the migrated Java code. The >> `Object[] getSigners` is no longer `native`, thus requiring a CSR record. >> Reviewers please help review the associated CSR. > > Chen Liang has updated the pull request with a new target base due to a merge > or a rebase. The incremental webrev excludes the unrelated changes brought in > by the merge/rebase. The pull request contains three additional commits since > the last revision: > > - Merge branch 'master' of https://github.com/openjdk/jdk into > feature/class-signers > - Reorder comment of classData to avoid misunderstanding > - 8334772: Change Class::signers to an explicit field On the JVMTI side and the heapDumper ... I see that heapDumper explicitly fills in a slot for the classloader, but that is also an explicit field. Does that mean that the classloader appears twice, or does the fact it is filtered by reflection mean that the heapDumper doesn't see it when dumping fields? If the latter then it suggests to me that we should be doing the same for the signers. Otherwise I don't know what the implications might be for having the field listed twice. ------------- PR Review: https://git.openjdk.org/jdk/pull/20223#pullrequestreview-2186958021
