-
Notifications
You must be signed in to change notification settings - Fork 5.8k
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
Conversation
👋 Welcome back liach! A progress list of the required criteria for merging this PR into |
@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:
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
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 |
There was a problem hiding this 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:
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:
I think polymorphism is fine here, as after the check we usually go straight to perform type-specific operations like |
Confirmed this is performance-wise neutral for startup. Ready for review. |
There was a problem hiding this 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).
src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java
Outdated
Show resolved
Hide resolved
There was a problem hiding this 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)
src/java.base/share/classes/jdk/internal/constant/ArrayClassDescImpl.java
Outdated
Show resolved
Hide resolved
// Class.forName is slow on class or interface arrays | ||
Class<?> clazz = element.resolveConstantDesc(lookup); | ||
for (int i = 0; i < rank; i++) | ||
clazz = clazz.arrayType(); |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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()
.
src/java.base/share/classes/jdk/internal/constant/MethodTypeDescImpl.java
Show resolved
Hide resolved
src/java.base/share/classes/jdk/internal/constant/ReferenceClassDescImpl.java
Outdated
Show resolved
Hide resolved
@JornVernee I have updated the implementation class name and the factories for clarity. |
There was a problem hiding this 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.
There was a problem hiding this 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.
src/java.base/share/classes/jdk/internal/constant/ArrayClassDescImpl.java
Outdated
Show resolved
Hide resolved
src/java.base/share/classes/jdk/internal/constant/ArrayClassDescImpl.java
Outdated
Show resolved
Hide resolved
Thanks for the reviews; can anyone review the associated CSR at https://bugs.openjdk.org/browse/JDK-8340963 as well? |
src/java.base/share/classes/jdk/internal/constant/ConstantUtils.java
Outdated
Show resolved
Hide resolved
@liach this pull request can not be integrated into 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 |
Turns out ArrayClassDesc::displayName was incorrect. Added a test.
Just noticed that the |
There was a problem hiding this 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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good.
Thanks for the reviews! /integrate |
Going to push as commit 25c2f48.
Your commit was automatically rebased without conflicts. |
There was a problem hiding this 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!
@cl4es discovered that Stack Map generation in ClassFile API uses
componentType
andarrayType
foraaload
aastore
instructions, which are currently quite slow. We can split out array class descriptors from class or interfaces to support fasterarrayType
andcomponentType
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
Issues
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