8305995: Footprint regression from JDK-8224957

[catap]

This is a fix for the regression introduced by da43cb5 in fix 8224957.

This regression was found while attempting to migrate an application from JDK 1.8 to JDK 17, by running internal benchmarks, and while investigating abnormal memory usage for about 4 times more from one of them.

The regression appears in the JMH benchmark, which builds a huge tree which contains boxed integers from 0 to a few thousand. A tree has very complex structure and the same objects are reused a lot.

When an integer is found it's collected as Integer and unboxed inside the collector callback.

This benchmark was run with ParallelGC on different JVMs: JDK 1.8.0_362, JDK 11.0.18, JDK 13.0.13, JDK 15.0.9, JDK 17.0.6, JDK 19.0.2 and JDK 20. This allows to see that something has changed between 13 and 15, and that the memory footprint for this code has increased from 3152 to 11828 bytes per operation.

After that I've done a git bisect which allows me to locate the introducer.

So the current fix reduces the memory footprint on the local root 425ef06 to 2960 bytes per operation.

---

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-8305995: Footprint regression from JDK-8224957

Reviewers

• Vladimir Kozlov (@vnkozlov - Reviewer)
• Tobias Hartmann (@TobiHartmann - Reviewer)

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 13453

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

Using diff file

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

Webrev

Link to Webrev Comment

[bridgekeeper]

Hi @catap, 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 catap" 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]

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

• hotspot-compiler

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.

[catap]

/signed

[bridgekeeper]

Thank you! Please allow for up to two weeks to process your OCA, although it is usually done within one to two business days. Also, please note that pull requests that are pending an OCA check will not usually be evaluated, so your patience is appreciated!

[openjdk]

@catap Please do not rebase or force-push to an active PR as it invalidates existing review comments. Note for future reference, the bots always squash all changes into a single commit automatically as part of the integration. See OpenJDK Developers’ Guide for more information.

[catap]

I've minimized my code to a trivial benchmark https://gist.github.com/catap/3ac65ba878048cca0132e6cba17d86ba which shown that effect of this patch is reducing memory footprint 20 times.

[TobiHartmann]

Thanks for reporting this, Kirill. I filed JDK-8305995 for tracking. It would be great if you could add your benchmark (to test/micro/org/openjdk/bench/). I'll have a look at your proposed fix next week.

[mlbridge]

Webrevs

• 03: Full - Incremental (18b997f9)
• 02: Full - Incremental (4cd22b60)
• 01: Full - Incremental (dbc3ebf9)
• 00: Full (82c77579)

[vnkozlov]

First, please update PR's title, it should match JBS's title.
Second, @catap you referenced JMH benchmark. Is it already in test/micro/org/openjdk/bench/ or it is new? Please add it if it is new.

So before 8224957 code looks through in(1) for req() > 3 (and == 2). After 8224957 we bailout for >3 inputs.
This fix removed this restriction and we now go through all inputs for case > 3 inputs.
It may increase compilation time for such cases significantly but on other hand it may allow reduce IR.

I assume, based on description, x4 increase is in Java heap due to not unboxing some Java objects. Or is it memory consumed by C2 Jit compiler during benchmark execution?

[catap]

@vnkozlov after spending some time to simplify my benchmark and to include it into PR as the next commit, I'd like to conclude that boxing / unboxing aren't doing anything with it.

I just made a force push which contains the benchmark. JMH reports that it almost hasn't got memory footprint in runtime ≈ 10⁻³ on JDK up to 13 includes, but on JDK 15 and after that it consumes ≈ 7536.

So, in fact it isn't x4, I was wrong on the first assumption. It is much bigger.

P.S. I've also rewrite the commit message and include issue ID into it.

[openjdk]

@catap Please do not rebase or force-push to an active PR as it invalidates existing review comments. Note for future reference, the bots always squash all changes into a single commit automatically as part of the integration. See OpenJDK Developers’ Guide for more information.

[vnkozlov]

Thank you for adding benchmark. Please use meaningful name for benchmark and add copyright header to it. See other benchmarks there as example.

[vnkozlov]

And add benchmark's output as comment and what machine you used to run it.

[catap]

@vnkozlov may you suggest any meaningful name? :) RBTreeSearch is good enough?

[catap]

Renamed. I've run it as make test TEST="micro:RBTreeSearch" MICRO_OPTIONS="-prof gc" and have an output on my branch:

Benchmark                                 Mode  Cnt   Score    Error   Units
RBTreeSearch.search                      thrpt   12   0.079 ±  0.013  ops/us
RBTreeSearch.search:·gc.alloc.rate       thrpt   12  ≈ 10⁻⁴           MB/sec
RBTreeSearch.search:·gc.alloc.rate.norm  thrpt   12   0.003 ±  0.001    B/op
RBTreeSearch.search:·gc.count            thrpt   12     ≈ 0           counts

if I revert my changes by git diff ..origin/master -- src/hotspot/share/opto/node.cpp | patch -p1 for example and re-run test I do have an output:

Benchmark                                 Mode  Cnt     Score    Error   Units
RBTreeSearch.search                      thrpt   12     0.044 ±  0.009  ops/us
RBTreeSearch.search:·gc.alloc.rate       thrpt   12   209.072 ± 42.450  MB/sec
RBTreeSearch.search:·gc.alloc.rate.norm  thrpt   12  5024.005 ±  0.001    B/op
RBTreeSearch.search:·gc.count            thrpt   12    17.000           counts
RBTreeSearch.search:·gc.time             thrpt   12    17.000               ms

As you may see memory footprint quite different.

As test machine I use right now macOS 12.6.3. I may find some linux, but I doubt that this logic is os specific.

[vnkozlov]

New test's name is fine. Please, update copyright year (first line) to 2023.

Thank you for data. It shows that C2 did not eliminate Integer boxing allocations without your fix. As result they consume Java heap. With your fix C2's Escape Analysis eliminated these allocations.

Good!

I will submit internal testing for your changes.

[vnkozlov]

My testing passed.

[openjdk]

@catap 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:

8305995: Footprint regression from JDK-8224957

Reviewed-by: kvn, thartmann

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

• 02347d0: 8305351: C2 setScopedValueCache intrinsic doesn't use access API
• 2240c7e: 8305543: Ensure GC barriers for arraycopy on AArch64 use caller saved neon temp registers
• 1958f0e: 8305233: G1: Refactor G1ClearCardTableTask
• dbd2b5f: 8305892: G1: Fix G1MMUTracker::when_sec documentation
• c0b4957: 8305740: C2: add print statements to assert: Can't determine return type.
• 5c95bb1: 8257967: JFR: Events for loaded agents
• 2a062f1: 8305089: Implement missing socket options on AIX
• 7f56de8: 8306036: Use @APinote in String.toLowerCase, String.toUpperCase
• e575924: 8305336: java.security.debug=sunpkcs11 breaks PKCS#11 configuration with slotListIndex
• caa841d: 8306029: ProblemList runtime/ErrorHandling/TestDwarf.java on linux
• ... and 29 more: https://git.openjdk.org/jdk/compare/425ef0685c584abec80454fbcccdcc6db6558f93...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 (@vnkozlov, @TobiHartmann) 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).

[catap]

/integrate

[openjdk]

@catap
Your change (at version 18b997f) is now ready to be sponsored by a Committer.

[TobiHartmann]

Looks good to me too. Thanks for fixing this!

[TobiHartmann]

/sponsor

[openjdk]

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

• 02347d0: 8305351: C2 setScopedValueCache intrinsic doesn't use access API
• 2240c7e: 8305543: Ensure GC barriers for arraycopy on AArch64 use caller saved neon temp registers
• 1958f0e: 8305233: G1: Refactor G1ClearCardTableTask
• dbd2b5f: 8305892: G1: Fix G1MMUTracker::when_sec documentation
• c0b4957: 8305740: C2: add print statements to assert: Can't determine return type.
• 5c95bb1: 8257967: JFR: Events for loaded agents
• 2a062f1: 8305089: Implement missing socket options on AIX
• 7f56de8: 8306036: Use @APinote in String.toLowerCase, String.toUpperCase
• e575924: 8305336: java.security.debug=sunpkcs11 breaks PKCS#11 configuration with slotListIndex
• caa841d: 8306029: ProblemList runtime/ErrorHandling/TestDwarf.java on linux
• ... and 29 more: https://git.openjdk.org/jdk/compare/425ef0685c584abec80454fbcccdcc6db6558f93...master

Your commit was automatically rebased without conflicts.

[openjdk]

@TobiHartmann @catap Pushed as commit 7551529.

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

[catap]

/backport jdk17u-dev

[openjdk]

@catap To use the /backport command, you need to be in the OpenJDK census and your GitHub account needs to be linked with your OpenJDK username (how to associate your GitHub account with your OpenJDK username).

[catap]

@TobiHartmann / @vnkozlov may it also be backported to jdk17?

[TobiHartmann]

We (Oracle) will backport it to Oracle JDK 17u after some bake time in mainline. It's then up to the OpenJDK community to backport it to OpenJDK 17u as well but I think it's likely that they will do so.

[catap]

@TobiHartmann thanks, it's clear. But can I expect that this fix will be the next release of JDK17?

[TobiHartmann]

This will most likely go into JDK 17.0.8 but it depends on if and when the fix is backported.