8372098: Move AccessFlags to InstanceKlass

[coleenp]

ArrayKlass doesn't set AccessFlags so don't look for them there. See CR for details.
Fixed SA and jvmci. @iwanowww Can you check that I changed C2 correctly (we talked about this in August).
Tested with tier1-4. 5-7 in progress.

---

Progress

• Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• Change must not contain extraneous whitespace
• Commit message must refer to an issue

Issue

• JDK-8372098: Move AccessFlags to InstanceKlass (Enhancement - P4)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/28371/head:pull/28371
$ git checkout pull/28371

Update a local copy of the PR:
$ git checkout pull/28371
$ git pull https://git.openjdk.org/jdk.git pull/28371/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 28371

View PR using the GUI difftool:
$ git pr show -t 28371

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/28371.diff

Using Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back coleenp! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

[openjdk]

@coleenp The following labels will be automatically applied to this pull request:

• graal
• hotspot
• serviceability

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing lists. If you would like to change these labels, use the /label pull request command.

[liach]

I know a MethodRef can be [I, clone, ()Ljava/lang/Object; for intArray.clone() Java calls translated by javac. I wonder if this new code would break for such an array callee class.

[coleenp]

At one point, I removed is_interface() from class Klass, but then restored it because dependencies uses this a lot and has many Klass parameter types, instead of InstanceKlass. I'll revert this change, but I'm curious why none of the tests failed with this change.

[mlbridge]

Webrevs

• 02: Full - Incremental (1060463b)
• 01: Full - Incremental (e8973f59)
• 00: Full (80079012)

[ExE-Boss]

Note that a resolved CONSTANT_Class can refer to an array type, so this cast is incorrect.

[coleenp]

There are a bunch of tests that we don't have. This would be an error since Interfaces are never arrays, but that's checked later. I'll revert some of these casts (as well as try to write a test for this).

[liach]

I thought the cast at line 839 would have handled this. Turns out it has a !interf->is_interface() check before so this cast is problematic.

[coleenp]

There's a reason this isn't tested. The constant pool reference for JVM_CONSTANT_Class is tested to be resolved at line 814 and because it's an interface, it's not easy to be resolved by this point (unless it's a duplicate class in which case it will be an InstanceKlass). The array case goes through the else part of this and throws a ClassFormatError.