Skip to content

8338544: Dedicated Array class descriptor implementation #20665

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 20 commits into from

Conversation

liach
Copy link
Member

@liach liach commented Aug 21, 2024

@cl4es discovered that Stack Map generation in ClassFile API uses componentType and arrayType for aaload aastore instructions, which are currently quite slow. We can split out array class descriptors from class or interfaces to support faster arrayType and componentType operations.

Tentative, as I currently have no way to measure the actual impact of this patch on the startup performance; however, this made the ClassDesc implementations much cleaner.


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
  • Change requires CSR request JDK-8340963 to be approved

Issues

  • JDK-8338544: Dedicated Array class descriptor implementation (Sub-task - P4)
  • JDK-8340963: Make some ClassDesc methods no longer default (CSR)

Reviewers

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 20665

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

Using diff file

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

Webrev

Link to Webrev Comment

@bridgekeeper
Copy link

bridgekeeper bot commented Aug 21, 2024

👋 Welcome back liach! 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
Copy link

openjdk bot commented Aug 21, 2024

@liach This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8338544: Dedicated Array class descriptor implementation

Reviewed-by: redestad, mchung, jvernee

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 17 new commits pushed to the master branch:

  • 98403b7: 8342854: [JVMCI] Block secondary thread reporting a JVMCI fatal error
  • 9a7a850: 8341939: SigningOptionsTest fails without Xcode with command line developer tools after JDK-8341443
  • de92fe3: 8233451: (fs) Files.newInputStream() cannot be used with character special files
  • 002de86: 8342673: Test serviceability/jvmti/events/NotifyFramePopStressTest/NotifyFramePopStressTest.java failed: waited too long for notify
  • a21c558: 8342863: Use pattern matching for instanceof in equals methods of wrapper classes
  • e64f079: 8342582: user.region for formatting number no longer works for 21.0.5
  • 426da4b: 8341975: Unable to set encoding for IO.println, IO.print and IO.readln
  • a522d21: 8342858: Make target mac-jdk-bundle fails on chmod command
  • afb62f7: 8342683: Use non-short forward jump when passing stop()
  • 964d8d2: 8340445: [PPC64] Wrong ConditionRegister used in ppc64.ad: flagsRegCR0 cr1
  • ... and 7 more: https://git.openjdk.org/jdk/compare/d6eddcdaf92f2352266ba519608879141997cd63...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

@openjdk
Copy link

openjdk bot commented Aug 21, 2024

@liach The following label will be automatically applied to this pull request:

  • core-libs

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

@openjdk openjdk bot added the core-libs core-libs-dev@openjdk.org label Aug 21, 2024
Copy link

@ExE-Boss ExE-Boss left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Apparently, changing method default‑ness requires a CSR (even for fully sealed hierarchies), but I can’t find the PR where I was informed of this.


Using return this instanceof <type>ClassDescImpl might allow C2 to better avoid megamorphic virtual invocations (see GH‑17488), but this needs to be benchmarked:

@liach
Copy link
Member Author

liach commented Aug 27, 2024

I know this requires a CSR; it's just not created due to this still being a draft.

The main purpose of this is still for speeding up stack map generation; the results are not confirmed yet, so this patch is on hold.

For megamorphic call site thing, the regular workload would be like:

if (c.isArray()) doArrayStuff(c);
if (c.isClassOrInterface()) doClassOrInterfaceStuff(c);

I think polymorphism is fine here, as after the check we usually go straight to perform type-specific operations like componentType(); or sometimes a method expects the input ClassDesc to be always primitive/class or interface/array, which won't lead to profile pollutions. This concern might be more valid for descriptorString I suppose.

@liach
Copy link
Member Author

liach commented Sep 25, 2024

Confirmed this is performance-wise neutral for startup. Ready for review.

@liach liach marked this pull request as ready for review September 25, 2024 18:48
@openjdk openjdk bot added csr Pull request needs approved CSR before integration rfr Pull request is ready for review labels Sep 25, 2024
@mlbridge
Copy link

mlbridge bot commented Sep 25, 2024

Webrevs

Copy link
Member

@cl4es cl4es left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Always a bit queasy to add a third to a nice pair of classes, but if this ever shows up as a problem on benchmarks we can revisit and think of alternatives (such as adding a rank field in each impl).

Copy link
Member

@JornVernee JornVernee left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice cleanup! I'm just not really sure about the new subtype relationship (see inline comment)

// Class.forName is slow on class or interface arrays
Class<?> clazz = element.resolveConstantDesc(lookup);
for (int i = 0; i < rank; i++)
clazz = clazz.arrayType();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking at the implementation of arrayType, it reflectively creates an array and then returns its class. Just makes me think we need a better we to look up an array class directly in the JDK :D

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed; and it's more alarming that Class.forName("[[[[[Ljava.lang.Object;") is slower than Object.class.arrayType().arrayType().arrayType().arrayType().arrayType().

@liach
Copy link
Member Author

liach commented Oct 8, 2024

@JornVernee I have updated the implementation class name and the factories for clarity.

@liach liach requested review from JornVernee and cl4es October 8, 2024 01:35
Copy link
Member

@cl4es cl4es left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks reasonable to me.

An alternative could be to put an int rank in both PrimitiveClassDescImpl and ReferenceClassDescImpl. Would lead to slightly gnarlier code in places, but keep the number of classes down. Worth considering if any throughput benchmark sees fallout from going from 2 to 3 types.

The internalNameToDesc changes could perhaps better have been done in a separate PR but no point teasing it apart now.

Copy link
Member

@mlchung mlchung left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good with minor suggestion. I agree having a separate implementation class for array type and class/interface allows a cleaner subclass implementation.

@liach
Copy link
Member Author

liach commented Oct 8, 2024

Thanks for the reviews; can anyone review the associated CSR at https://bugs.openjdk.org/browse/JDK-8340963 as well?

@liach liach requested a review from JornVernee October 11, 2024 14:45
@openjdk
Copy link

openjdk bot commented Oct 18, 2024

@liach this pull request can not be integrated into master due to one or more merge conflicts. To resolve these merge conflicts and update this pull request you can run the following commands in the local repository for your personal fork:

git checkout feature/array-cd
git fetch https://git.openjdk.org/jdk.git master
git merge FETCH_HEAD
# resolve conflicts and follow the instructions given by git merge
git commit -m "Merge master"
git push

@openjdk openjdk bot added the merge-conflict Pull request has merge conflict with target branch label Oct 18, 2024
@openjdk openjdk bot removed the merge-conflict Pull request has merge conflict with target branch label Oct 22, 2024
@openjdk openjdk bot removed the csr Pull request needs approved CSR before integration label Oct 22, 2024
@openjdk openjdk bot added the csr Pull request needs approved CSR before integration label Oct 23, 2024
Turns out ArrayClassDesc::displayName was incorrect. Added a test.
@liach
Copy link
Member Author

liach commented Oct 23, 2024

Just noticed that the ArrayClassDesc::displayName was buggy - existing tests had no coverage and I have added test coverage for displayName and a few other missed methods.

Copy link
Member

@cl4es cl4es left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updates since last review looks good

Copy link
Member

@mlchung mlchung left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good.

@openjdk openjdk bot added ready Pull request is ready to be integrated and removed csr Pull request needs approved CSR before integration labels Oct 23, 2024
@liach
Copy link
Member Author

liach commented Oct 24, 2024

Thanks for the reviews!

/integrate

@openjdk
Copy link

openjdk bot commented Oct 24, 2024

Going to push as commit 25c2f48.
Since your change was applied there have been 19 commits pushed to the master branch:

  • 158b93d: 8335912: Add an operation mode to the jar command when extracting to not overwriting existing files
  • 28d23ad: 8340177: Malformed system classes loaded by bootloader crash the JVM in product builds
  • 98403b7: 8342854: [JVMCI] Block secondary thread reporting a JVMCI fatal error
  • 9a7a850: 8341939: SigningOptionsTest fails without Xcode with command line developer tools after JDK-8341443
  • de92fe3: 8233451: (fs) Files.newInputStream() cannot be used with character special files
  • 002de86: 8342673: Test serviceability/jvmti/events/NotifyFramePopStressTest/NotifyFramePopStressTest.java failed: waited too long for notify
  • a21c558: 8342863: Use pattern matching for instanceof in equals methods of wrapper classes
  • e64f079: 8342582: user.region for formatting number no longer works for 21.0.5
  • 426da4b: 8341975: Unable to set encoding for IO.println, IO.print and IO.readln
  • a522d21: 8342858: Make target mac-jdk-bundle fails on chmod command
  • ... and 9 more: https://git.openjdk.org/jdk/compare/d6eddcdaf92f2352266ba519608879141997cd63...master

Your commit was automatically rebased without conflicts.

@openjdk openjdk bot added the integrated Pull request has been integrated label Oct 24, 2024
@openjdk openjdk bot closed this Oct 24, 2024
@openjdk openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels Oct 24, 2024
@openjdk
Copy link

openjdk bot commented Oct 24, 2024

@liach Pushed as commit 25c2f48.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

Copy link
Member

@JornVernee JornVernee left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Latest version looks good.

P.S. Oh, looks like the tab I had open for this PR wasn't updated. Didn't see it was already merged. All good!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
core-libs core-libs-dev@openjdk.org integrated Pull request has been integrated
Development

Successfully merging this pull request may close these issues.

5 participants