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 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.
* Don't assume the underlying intrinsic can handle isMIME or isURL modes, but also let them decide if they will process the data regardless of the settings of the two booleans.
* 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 will simply return -1, instead of requiring it to throw a proper exception from the context of the intrinsic. In the event of getting a -1 returned from the intrinsic, the Java Base64 library code simply calls the pure Java implementation to have it find the error and properly throw an exception. This is a performance trade-off in the case of an error (which I expect to be very rare).
* One thought I have for a further optimization (not implemented in the current patch), is that when the intrinsic decides not to process a block because of some combination of isURL and isMIME settings it doesn't handle, it could return extra bits in the return code, encoded as a negative number. For example:
Illegal_Base64_char = 0b001;
isMIME_unsupported = 0b010;
isURL_unsupported = 0b100;
These can be OR'd together as needed and then negated (flip the sign). The Base64 library code could then cache these flags, so it will know not to call the intrinsic again when another decodeBlock is requested but with an unsupported mode. This will save the performance hit of calling the intrinsic when it is guaranteed to fail.
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.
* Don't assume the underlying intrinsic can handle isMIME or isURL modes, but also let them decide if they will process the data regardless of the settings of the two booleans.
* 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 will simply return -1, instead of requiring it to throw a proper exception from the context of the intrinsic. In the event of getting a -1 returned from the intrinsic, the Java Base64 library code simply calls the pure Java implementation to have it find the error and properly throw an exception. This is a performance trade-off in the case of an error (which I expect to be very rare).
* One thought I have for a further optimization (not implemented in the current patch), is that when the intrinsic decides not to process a block because of some combination of isURL and isMIME settings it doesn't handle, it could return extra bits in the return code, encoded as a negative number. For example:
Illegal_Base64_char = 0b001;
isMIME_unsupported = 0b010;
isURL_unsupported = 0b100;
These can be OR'd together as needed and then negated (flip the sign). The Base64 library code could then cache these flags, so it will know not to call the intrinsic again when another decodeBlock is requested but with an unsupported mode. This will save the performance hit of calling the intrinsic when it is guaranteed to fail.
- duplicates
-
JDK-8216439 PPC64: Add intrinsic for Base64 algorithm
-
- Closed
-
