8365880: Shenandoah: Unify memory usage accounting in ShenandoahFreeSet

[kdnilsen]

This PR eliminates redundant bookkeeping that had been carried out by both ShenandoahGeneration and ShenandoahFreeSet. In the new code, we keep a single tally of relevant information within ShenandoahFreeSet.
Queries serviced by ShenandoahGeneration are now delegated to ShenandoahFreeSet.

This change eliminates rare and troublesome assertion failures that were often raised when the ShenandoahFreeSet tallies did not match the ShenandoahGeneration tallies. These assertion failures resulted because the two sets of books are updated at different times, using different synchronization mechanisms.

The other benefit of this change is that we have less synchronization overhead because we only have to maintain a single set of books.

---

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-8365880: Shenandoah: Unify memory usage accounting in ShenandoahFreeSet (Task - P4)

Reviewers

• William Kemper (@earthling-amzn - Reviewer)

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 26867

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

Using diff file

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

Using Webrev

Link to Webrev Comment

[openjdk]

@kdnilsen serviceability has been added to this pull request based on files touched in new commit(s).

[kdnilsen]

I'm not convinced the change above to move the constraints check sooner is needed in order to use the value of SoftMaxHeapSize in ShenandoahHeap::initialize().

What's the error you see without this change?

I did some testing after reverting my change to the shared code, and I wasn't able to identify exactly how this change relates to particular regression failures. I've committed new changes to mitigate the issues without changing shared code:

1. Inside ShenandoahHeap::initialize(), we clamp the assignment to _soft_max_size between min_capacity() and max_capacity()
2. In ShenandoahHeap::post_initialize(), we check_soft_max_changed(). This will change the value of _soft_max_size if the current value of SoftMaxHeapSize, which has now had its constraints enforced, differs from the current value of _soft_max_size. Constraints are enforced following initialize() but before post_initialize().

[earthling-amzn]

Just a nit, but the other variables here use Java's camel case convention, so should probably have allowedRetries, not allowed_retries.

[kdnilsen]

/integrate

[openjdk]

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

• 1781b18: 8343232: PKCS#12 KeyStore support for RFC 9879: Use of Password-Based Message Authentication Code 1 (PBMAC1)
• 8236800: 8370527: Memory leak after 8316694: Implement relocation of nmethod within CodeCache
• 16dafc0: 8370393: Cleanup handling of ancient Windows versions from GetJavaProperties java_props_md
• ... and 11 more: https://git.openjdk.org/jdk/compare/6347f10bf1dd3959cc1f2aba32e72ca8d9d56e82...master

Your commit was automatically rebased without conflicts.

[openjdk]

@kdnilsen Pushed as commit ec059c0.

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