8269404: Base64 Encoding optimization enhancements for x86 using AVX-512

[asgibbons]

This is a backport of JDK-8269404: Base64 Encoding optimization enhancements for x86 using AVX-512. Backport is clean.

We have had numerous customer requests for this functionality to be backported due to the performance improvement.

There will be three additional PRs for which this is a dependency. This PR is dependent on PR #860.

Risk: I view the risk of this backport to be minimal. This code has been in use for many months with no bugs reported.

Testing: x86_64 build, affected tests, tier1

Thanks,
--Scott

---

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-8269404: Base64 Encoding optimization enhancements for x86 using AVX-512

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk17u-dev pull/861/head:pull/861
$ git checkout pull/861

Update a local copy of the PR:
$ git checkout pull/861
$ git pull https://git.openjdk.org/jdk17u-dev pull/861/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 861

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

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk17u-dev/pull/861.diff

[bridgekeeper]

👋 Welcome back asgibbons! A progress list of the required criteria for merging this PR into pr/860 will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

This backport pull request has now been updated with issue from the original commit.

[mlbridge]

Webrevs

• 02: Full - Incremental (e661488a)
• 01: Full - Incremental (e8ff3f11)
• 00: Full (e8ff3f11)

[GoeLin]

What is wrong with the pre-submit tests?
In addition, I will run the five changes through our testing.

[asgibbons]

Thanks, Goetz. The failure is in TestStringDeduplicationTools and is caused by improper 64-byte alignment of data structures. This bug was found and fixed with the subsequent PR (#862). The bug will show up sporadically and depends on the stub code generation process.

Please let me know how I should handle this.

[asgibbons]

/integrate
Thanks, Goetz.

[openjdk]

@asgibbons This pull request has not yet been marked as ready for integration.

[dwhite-intel]

/sponsor

[openjdk-notifier]

The parent pull request that this pull request depends on has now been integrated and the target branch of this pull request has been updated. This means that changes from the dependent pull request can start to show up as belonging to this pull request, which may be confusing for reviewers. To remedy this situation, simply merge the latest changes from the new target branch into this pull request by running commands similar to these in the local repository for your personal fork:

git checkout Encode-backport
git fetch https://git.openjdk.org/jdk17u-dev master
git merge FETCH_HEAD
# if there are conflicts, follow the instructions given by git merge
git commit -m "Merge master"
git push

[openjdk]

@dwhite-intel The change author (@asgibbons) must issue an integrate command before the integration can be sponsored.

[asgibbons]

/integrate

[openjdk]

@asgibbons This pull request has not yet been marked as ready for integration.

[asgibbons]

/clean

[openjdk]

@asgibbons Only OpenJDK Committers can use the /clean command

[dwhite-intel]

/sponsor

[openjdk]

@dwhite-intel The change author (@asgibbons) must issue an integrate command before the integration can be sponsored.

[asgibbons]

/integrate

[openjdk]

@asgibbons This pull request has not yet been marked as ready for integration.

[dwhite-intel]

/sponsor

[openjdk]

@dwhite-intel The change author (@asgibbons) must issue an integrate command before the integration can be sponsored.

[asgibbons]

@GoeLin This seems not to be the way in which I would see dependent PRs handled. It appears that the bot added the dependent PRs commit to this commit, which should not happen. If the previous commit was merged into master, and this commit was retargeted to master, the previous PR should not be re-applied. It is already in master and should not appear here.

I may not fully understand the dependent PR process, so clarification would be appreciated. I'm referencing an email from Erik Helin and Robin ?? entitled "New Skara feature: dependent pull requests" dated Mar 23, 2021.

As can be seen from this PR's history, the patch was clean before the previous PR was integrated. Then once the previous was integrated, this PR shows conflicts. I did this manually (cloned openjdk/jdk17u-dev:master, then backported the patch) which worked as advertised.

Please help. Thanks.

[asgibbons]

Created a clean PR #867

[asgibbons]

Closing this because of dependent PR issues.