RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding [v6]

[CoreyAshford]

> This patch set encompasses the following commits:
> 
> - Adds a new HotSpot intrinsic candidate to the java.lang.Base64 class - decodeBlock(), and provides a flexible API for
>   the intrinsic.  The API is similar to the existing encodeBlock intrinsic.
> - Adds the code in HotSpot to check and martial the new intrinsic's arguments to the arch-specific intrinsic
>   implementation
> - Adds a Power64LE-specific implementation of the decodeBlock intrinsic.
> - Adds a JMH microbenchmark for both Base64 encoding and encoding.
> - Enhances the JTReg hotspot intrinsic "TestBase64.java" regression test to more fully test both decoding and encoding.

CoreyAshford has updated the pull request with a new target base due to a merge or a rebase. The pull request now
contains 22 commits:

 - CheckGraalIntrinsics.java: Disable testing of decodeBlock intrinsic until implemented for AMD64/x86
 - Merge branch 'master' of https://git.openjdk.java.net/jdk into base64_decode_intrinsic
 - stubGenerator_ppc.cpp: remove unnecessary complexity for checking < 0 after srawi.
 - Per Martin Doerr's v4 review: fix regression, and speed up return time for buffers that are too small
   
    - Check for case where the result of subtacting 12 off of the source
      length produces a negative number.  To do this efficiently, I added the
      instruction definition for mcrxrx, which is implemented on Power9+.
   
    - Rearrange the code so that minimal initialization is performed before
      checking the size, so that the intrinsic can return quickly in the event
      that the buffer is too small to process.
 - TestBase64.java: fix comment to correctly reflect actual intrinsic names.
   
   The intrinsic names that are visible with -XX:+PrintCompilation are encode
   and decode, rather than encodeBlock and decodeBlock.
 - stubGenerator_ppc.cpp: fix regression caused by change to using loop counter
   
   My original fix didn't account for the case where sl < block_size.  In the
   event sl < block_size, the shifted sl will become zero, so it should
   jump to the code that computes how much data was processed - 0 - and return.
 - stubGenerator_ppc.cpp: Fix multiple issues as per Martin Doerr's v2 review
   
    * Remove extraneous comma from SAP copyright notice
    * Move align(32) to the head of the loop rather than the beginning of the unwound code
    * Simplified looping condition to use a loop counter instead of a final
      address.  This eliminated the need for the "end" variable, and
      essentially replaced it with CTR, which is computed using a simple
      bitwise shift of the size.
    * Re-ran benchmarks against loop_unrolls values: 1, 2, 4, 8, 16 to find
      optimal value, now 4.
    * Corrected a typo in the word "elements"
 - vm_version_ppc.cpp: per Martin Doerr's review of v2: fix copy/paste error
 - vmIntrinsics.cpp: Per Martin Doerr's v2 review: rearrange order of case statement to be consistent with others.
 - runtime.cpp: per Martin Doerr's review of v2, correct comment as per current semantics of decodeBlock()
   
     * The reference to "ofs" seems to be a copy/paste error.
     * -1 is no longer returned from decodeBlock() in the event of a
       non-base64 character being encountered; only a count of bytes written
       to dst.
 - ... and 12 more: https://git.openjdk.java.net/jdk/compare/3ccf4877...dcd15d57

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

Changes: https://git.openjdk.java.net/jdk/pull/293/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=293&range=05
  Stats: 1894 lines in 25 files changed: 1866 ins; 4 del; 24 mod
  Patch: https://git.openjdk.java.net/jdk/pull/293.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/293/head:pull/293

PR: https://git.openjdk.java.net/jdk/pull/293