RFR(S): 8248188 Add HotSpotIntrinsicCandidate and API for Base64 decoding (repost to correct mailing list)

[Corey Ashford]

Hello,

I had originally made two posts to the hotspot-compiler-dev and 
ppc-aix-port-dev mailing lists, but since this RFR requires modifying 
the core library code, it makes sense to post it to core-lib-devs instead.

The two original posts:

https://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2020-June/004110.html

https://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2020-July/004115.html

Webrev: http://cr.openjdk.java.net/~mhorie/8248188/webrev.01/

To recap the current state:

Currently in java.util.Base64, there is a HotSpotIntrinsicCandidate and 
API for encodeBlock, but none for decoding.  This means that only 
encoding gets acceleration from the underlying CPU's vector or other 
accelerator hardware.

I'd like to propose adding a new intrinsic for decodeBlock.  The 
considerations I have for this new intrinsic's API:

  * Don't make any assumptions about the underlying capability of the 
hardware.  For example, do not impose any specific block size granularity.

  * Because of the difficulty of handling the isMIME=true option in a 
vector-based accelerator, do not call this intrinsic when isMIME=true. 
If desired, a new HotSpotIntrinsicCandidate can be introduced in the 
future for this case.

  * Any remaining data that is not processed by the intrinsic will be 
processed by the pure Java implementation.  This allows the intrinsic to 
process whatever block sizes it's good at without the complexity of 
handling the end fragments.

  * If any illegal character is discovered in the decoding process, the 
intrinsic can return 0, or any number of bytes produced, up to but not 
including the byte containing the error.  At this point, the pure-Java 
algorithm will be called, which will discover the error and report it 
via a thrown exception as usual.

I've tested the patch in the webrev with an actual intrinsic coded up 
for Power9/Power10, but that runtime intrinsic and arch-specific patches 
aren't in the webrev, because I want to get some consensus on the 
library-level intrinsic API first.

I'm open to any comments about this.

Thanks for your consideration,

- Corey

Corey Ashford
Software Engineer
IBM Systems, LTC OpenJDK team
503-985-8699 Home office
cjashfor at us.ibm.com

IBM