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 3803:

> 3801:     // Base64 class will be used to process the last 12 characters.
> 3802:     __ sub(sl, sl, sp);
> 3803:     __ subi(sl, sl, 12);

I think we should subtract 4, now. srawi will round it down below. We have no guarantee that we can subract more than 4
without getting negative value.

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

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