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

[Martin Doerr]

On Thu, 8 Oct 2020 20:31:47 GMT, CoreyAshford <github.com+51754783+CoreyAshford at openjdk.org> wrote:

>> 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 incrementally with two additional commits since the last revision:
> 
>  - 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.

src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 3745:

> 3743:     __ clrldi(isURL, isURL, 32);
> 3744:
> 3745:     // Load constant vec registers that need to be loaded from memory

With larger unroll factor we run through this code more often without making any progress, because only the Java part
does all the work for the remaining bytes. Would be nice to move unnecessary parts for that between mtctr and align.

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

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