8332249: Micro-optimize Method.hashCode

[sgwizdak-aws]

Improve the speed of Method.hashCode by caching the hashcode on first use. I've seen an application where Method.hashCode is a hot path, and this is a fairly simple speedup. The memory overhead is low.

This addresses issue JDK-8332249.

Before:

Benchmark                         Mode  Cnt  Score   Error  Units
# Intel Skylake
MethodHashCode.benchmarkHashCode  avgt    5  1.843 ± 0.149  ns/op
# Arm Neoverse N1
MethodHashCode.benchmarkHashCode  avgt    5  2.363 ± 0.091  ns/op

After:

Benchmark                         Mode  Cnt  Score   Error  Units
# Intel Skylake
MethodHashCode.benchmarkHashCode  avgt    5  1.121 ± 1.189  ns/op
# Arm Neoverse N1
MethodHashCode.benchmarkHashCode  avgt    5  1.001 ± 0.001  ns/op

---

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-8332249: Micro-optimize Method.hashCode (Enhancement - P4)

Reviewers

• Chen Liang (@liach - Reviewer)

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 19433

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

Using diff file

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

Webrev

Link to Webrev Comment

[bridgekeeper]

Hi @s-gwizdak, welcome to this OpenJDK project and thanks for contributing!

We do not recognize you as Contributor and need to ensure you have signed the Oracle Contributor Agreement (OCA). If you have not signed the OCA, please follow the instructions. Please fill in your GitHub username in the "Username" field of the application. Once you have signed the OCA, please let us know by writing /signed in a comment in this pull request.

If you already are an OpenJDK Author, Committer or Reviewer, please click here to open a new issue so that we can record that fact. Please use "Add GitHub user s-gwizdak" as summary for the issue.

If you are contributing this work on behalf of your employer and your employer has signed the OCA, please let us know by writing /covered in a comment in this pull request.

[openjdk]

@s-gwizdak 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:

8332249: Micro-optimize Method.hashCode

Reviewed-by: liach

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 485 new commits pushed to the master branch:

• 84c74ad: 8335802: Improve startup speed HexFormat uses boolean instead of enum
• 4f312d6: 8336152: Remove unused forward declaration in classLoadInfo.hpp
• 34d8562: 8335902: Parallel: Refactor VM_ParallelGCFailedAllocation and VM_ParallelGCSystemGC
• 2fc7eb4: 8155030: The Menu Mnemonics are always displayed for GTK LAF
• 559826c: 8332474: Tighten up ToolBox' JavacTask to not silently accept javac crash as a failure
• eec0e15: 8335619: Add an @APinote to j.l.i.ClassFileTransformer to warn about recursive class loading and ClassCircularityErrors
• 9b6f6c5: 8336082: Fix -Wzero-as-null-pointer-constant warnings in SimpleCompactHashtable
• 7a62032: 8336081: Fix -Wzero-as-null-pointer-constant warnings in JVMTypedFlagLimit ctors
• f677b90: 8267887: RMIConnector_NPETest.java fails after removal of RMI Activation (JDK-8267123)
• 1fe3ada: 8336284: Test TestClhsdbJstackLock.java/TestJhsdbJstackLock.java fails with -Xcomp after JDK-8335743
• ... and 475 more: https://git.openjdk.org/jdk/compare/9686e804a2b058955ff88149c54a0a7896c0a2eb...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.

As you do not have Committer status in this project an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@liach) but any other Committer may sponsor as well.

➡️ To flag this PR as ready for integration with the above commit message, type /integrate in a new comment. (Afterwards, your sponsor types /sponsor in a new comment to perform the integration).

[openjdk]

@s-gwizdak 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.

[sgwizdak-aws]

/covered

[bridgekeeper]

Thank you! Please allow for a few business days to verify that your employer has signed the OCA. Also, please note that pull requests that are pending an OCA check will not usually be evaluated, so your patience is appreciated!

[liach]

Also, have you considered micro-optimize Constructor.hashCode too? Given its similar status to Method.

[sgwizdak-aws]

Also, have you considered micro-optimize Constructor.hashCode too? Given its similar status to Method.

Not at this time. This PR is motivated by observing Method.hashCode as a hotspot in a Spring heavy application when migrating to an ARM based platform. We did not observe Constructor.hashCode to be a hotspot in this application.

[mlbridge]

Webrevs

• 01: Full - Incremental (4364d99d)
• 00: Full (2e4c0c94)

[sgwizdak-aws]

Minor change after draft review -- moved Method hashCode benchmark into the newly created MethodBenchmark file.

[shipilev]

As usual in these cases, we need to make a footprint argument as well. Method is a special class with lots of injected fields, so the only "true" source of layout information is -XX:+PrintFieldLayout. It tells me there is a 4-byte tail due to object alignment in compressed oops mode. This can accommodate a new int field. There seems to be no space when compressed oops are disabled.

# Out of the box, compressed oops enabled
Layout of class java/lang/reflect/Method
Instance fields:
 @0 12/- RESERVED
 @12 "override" Z 1/1 INHERITED
 @13 "callerSensitive" B 1/1 REGULAR
 @14 2/1 EMPTY
 @16 "accessCheckCache" Ljava/lang/Object; 4/4 INHERITED
 @20 "parameterData" Ljava/lang/reflect/Executable$ParameterData; 4/4 INHERITED
 @24 "declaredAnnotations" Ljava/util/Map; 4/4 INHERITED
 @28 "slot" I 4/4 REGULAR
 @32 "modifiers" I 4/4 REGULAR
 @36 "clazz" Ljava/lang/Class; 4/4 REGULAR
 @40 "name" Ljava/lang/String; 4/4 REGULAR
 @44 "returnType" Ljava/lang/Class; 4/4 REGULAR
 @48 "parameterTypes" [Ljava/lang/Class; 4/4 REGULAR
 @52 "exceptionTypes" [Ljava/lang/Class; 4/4 REGULAR
 @56 "signature" Ljava/lang/String; 4/4 REGULAR
 @60 "genericInfo" Lsun/reflect/generics/repository/MethodRepository; 4/4 REGULAR
 @64 "annotations" [B 4/4 REGULAR
 @68 "parameterAnnotations" [B 4/4 REGULAR
 @72 "annotationDefault" [B 4/4 REGULAR
 @76 "methodAccessor" Ljdk/internal/reflect/MethodAccessor; 4/4 REGULAR
 @80 "root" Ljava/lang/reflect/Method; 4/4 REGULAR
Instance size = 88 bytes

# -XX:-UseCompressedOops
Layout of class java/lang/reflect/Method
Instance fields:
 @0 12/- RESERVED
 @12 "override" Z 1/1 INHERITED
 @13 "callerSensitive" B 1/1 REGULAR
 @14 2/1 EMPTY
 @16 "accessCheckCache" Ljava/lang/Object; 8/8 INHERITED
 @24 "parameterData" Ljava/lang/reflect/Executable$ParameterData; 8/8 INHERITED
 @32 "declaredAnnotations" Ljava/util/Map; 8/8 INHERITED
 @40 "slot" I 4/4 REGULAR
 @44 "modifiers" I 4/4 REGULAR
 @48 "clazz" Ljava/lang/Class; 8/8 REGULAR
 @56 "name" Ljava/lang/String; 8/8 REGULAR
 @64 "returnType" Ljava/lang/Class; 8/8 REGULAR
 @72 "parameterTypes" [Ljava/lang/Class; 8/8 REGULAR
 @80 "exceptionTypes" [Ljava/lang/Class; 8/8 REGULAR
 @88 "signature" Ljava/lang/String; 8/8 REGULAR
 @96 "genericInfo" Lsun/reflect/generics/repository/MethodRepository; 8/8 REGULAR
 @104 "annotations" [B 8/8 REGULAR
 @112 "parameterAnnotations" [B 8/8 REGULAR
 @120 "annotationDefault" [B 8/8 REGULAR
 @128 "methodAccessor" Ljdk/internal/reflect/MethodAccessor; 8/8 REGULAR
 @136 "root" Ljava/lang/reflect/Method; 8/8 REGULAR
Instance size = 144 bytes

[bridgekeeper]

@s-gwizdak This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

[sgwizdak-aws]

Adding a new comment per bot. @shipilev Any recommendations on reducing footprint size?

[liach]

Looks good as-is. JDK-8286288 can address the @Stable question once #19635 is merged.

[shipilev]

@shipilev Any recommendations on reducing footprint size?

I see two ways from here:

1. There seems to be a 2-byte gap in the object, so if we can squeeze out 2 additional bytes, it would allow us to put another int in. It looks like slot does not have to be int: on VM side, it is u2 (unsigned 2-byte), which might be just short or char with proper precautions about signs and conversions. That would probably be a bit ugly.

2. Ignore this regression and move on. It would have been a non-issue if Method-s were canonicalized/de-duplicated in some way. But AFAICS, Method-s are getting copied from Class.getDeclaredMethods, so it is probable we have quite a few instances floating around, and footprint regressions would stack up.

[sgwizdak-aws]

/integrate

[openjdk]

@s-gwizdak
Your change (at version 4364d99) is now ready to be sponsored by a Committer.

[liach]

I don't think we need to worry about the object footprint size. There are a few opportunities available, such as sharing the generic factories from the root object, or removing the unused slot field. And the hashcode cache will be required once we take parameter into account.

/sponsor

[openjdk]

Going to push as commit 8ba9bc6.
Since your change was applied there have been 487 commits pushed to the master branch:

• 4957145: 8336278: Micro-optimize Replace String.format("%n") to System.lineSeparator
• 1f6e106: 8335684: Test ThreadCpuTime.java should pause like ThreadCpuTimeArray.java
• 84c74ad: 8335802: Improve startup speed HexFormat uses boolean instead of enum
• 4f312d6: 8336152: Remove unused forward declaration in classLoadInfo.hpp
• 34d8562: 8335902: Parallel: Refactor VM_ParallelGCFailedAllocation and VM_ParallelGCSystemGC
• 2fc7eb4: 8155030: The Menu Mnemonics are always displayed for GTK LAF
• 559826c: 8332474: Tighten up ToolBox' JavacTask to not silently accept javac crash as a failure
• eec0e15: 8335619: Add an @APinote to j.l.i.ClassFileTransformer to warn about recursive class loading and ClassCircularityErrors
• 9b6f6c5: 8336082: Fix -Wzero-as-null-pointer-constant warnings in SimpleCompactHashtable
• 7a62032: 8336081: Fix -Wzero-as-null-pointer-constant warnings in JVMTypedFlagLimit ctors
• ... and 477 more: https://git.openjdk.org/jdk/compare/9686e804a2b058955ff88149c54a0a7896c0a2eb...master

Your commit was automatically rebased without conflicts.

[openjdk]

@liach @s-gwizdak Pushed as commit 8ba9bc6.

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

[liach]

Now in the review of #23972, we noted that String::hashCode couldn't constant fold as its hash and hashIsZero fields are missing @Stable. If string hash code and xor (see #23089) can constant fold, would this still be necessary?