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

[Corey Ashford]

This is an accidental duplicate post.  Please disregard.

On 8/10/20 2:00 PM, Corey Ashford wrote:
> 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