8350851: ZGC: Reduce size of ZAddressOffsetMax scaling data structures

[xmas92]

ZAddressOffsetMax is used to scale a few of our BitMap and GranuleMap data structures. ZAddressOffsetMax is initialised to an upper limit, prior to reserving the virtual address space for the heap. After the reservation, the largest address offset that can be encountered may be much lower.

I propose we scale ZAddressOffsetMax down after our heap reservation is complete, to the actual max value an zoffset_end is allowed to be.

Doing this gives us two benefits. Firstly the assertions and type checks will be stricter, and will exercise code paths that otherwise only occur when using a 16TB heap. Secondly we can reduce the size of the data structures which scale with ZAddressOffsetMax. (For most OSs the extra memory of these data structures do not really matter as they are not page'd in. But they are accounted for both on the OS, allocator and NMT layers).

The page table, uses ZIndexDistributor to iterate and distribute indices. The different strategies have different requirements on the alignment of the size of the range it distribute across. My proposed implementation simply aligns up the page table size to this alignment requirement. As it is the least intrusive change, at the cost of some larger data structure than strictly required. The alternative would be to extend ZIndexDistributor with support for any alignment on the range, or condition the use of the distributed indices based on if they are less than the size.

The data structures can also be larger than required if we fail to reserve the heap starting at our heap base. However this is a very rare occurrence, and while it would be nice to extend our asserts to check for a "ZAddressOffsetMin", I'll leave that for a future enhancement.

Testing:

• ZGC specific tasks, tier 1 through tier 8 on Oracle Supported platforms
  • with ZIndexDistributorStrategy=0, and
  • with ZIndexDistributorStrategy=1
• GHA

---

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-8350851: ZGC: Reduce size of ZAddressOffsetMax scaling data structures (Enhancement - P4)

Reviewers

• Erik Österlund (@fisk - Reviewer)
• Joel Sikström (@jsikstro - Committer)

Reviewers without OpenJDK IDs

• @abdelhak-zaaim (no known openjdk.org user name / role)

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 23822

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

Using diff file

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

Using Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back aboldtch! 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]

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

8350851: ZGC: Reduce size of ZAddressOffsetMax scaling data structures

Reviewed-by: eosterlund, jsikstro

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

• e98df71: 8348028: Unable to run gtests with CDS enabled
• d6c4be6: 8350758: G1: Use actual last prediction in accumulated survivor rate prediction too
• 2019f44: 8343832: Enhance test summary with number of skipped tests
• ac76d8d: 8350824: New async logging gtest StallingModePreventsDroppedMessages fails
• eada1ea: 8350855: RISC-V: print offset by assert of patch_offset_in_conditional_branch
• 2af76de: 8350683: Non-C2 / minimal JVM crashes in the build on ppc64 platforms
• ab4b0ef: 8350889: GenShen: Break out of infinite loop of old GC cycles
• 0a4c5a8: 8347804: GenShen: Crash with small GCCardSizeInBytes and small Java heap
• f1398ec: 8350701: [JMH] test foreign.AllocFromSliceTest failed with Exception for size>1024
• 3ae80bf: 8349766: GenShen: Bad progress after degen does not always need full gc
• ... and 9 more: https://git.openjdk.org/jdk/compare/01bd7e417ee3d39067370e616660b7f5c723dc26...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]

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

• hotspot-gc

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.

[mlbridge]

Webrevs

• 00: Full (1076cf3b)

[fisk]

Nice. Looks good.

[jsikstro]

Looks good!