RFR: JDK-8321599 Data loss in AVX3 Base64 decoding [v6]

[Scott Gibbons]

> Fix for looking for padding characters within the encoded string.  Was not adding start offset to length, so was looking at potentially freed or uninitialized memory.
> 
> Tested teir1 and with testcase supplied with JBS issue.
> 
> The problem will only occur when all of the following are true:
> 1. The source offset of the string to be decoded is != 0.
> 2. The characters at the beginning of the string (minus the offset) plus the string length mod 64 are either "=" or "==".
> 3. The string is >= 32 characters.
> 4. The string is not MIME encoded.
> 
> If any of these conditions are not met, the decode works as expected. This was due to omitting the source offset of the string when checking for padding characters.

Scott Gibbons has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:

 - Merge branch 'openjdk:master' into Base64-fix
 - Updated copyright year
 - Updated copyright year
 - Revert code size change - wa for an experiment only.
 - Added some comments to the test
 - Merge branch 'openjdk:master' into Base64-fix
 - Merge branch 'Base64-fix' of https://github.com/asgibbons/jdk into Base64-fix
 - Merge branch 'openjdk:master' into Base64-fix
 - Added tests for proper length and padding checks
 - Fix for JDK-8321599

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/17039/files
  - new: https://git.openjdk.org/jdk/pull/17039/files/f7d4705e..ba60ac59

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17039&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17039&range=04-05

  Stats: 136 lines in 10 files changed: 117 ins; 8 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/17039.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17039/head:pull/17039

PR: https://git.openjdk.org/jdk/pull/17039