> 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

Reply via email to