RFR: 8159035: com/sun/crypto/provider/Cipher/CTS/CTSMode.java test crashed due to unhandled case of cipher length value as 0

[Rahul Raghavan]

Hi,

Request review for closed bug fix - JDK-8159035.

<webrev> - http://cr.openjdk.java.net/~rraghavan/8159035/webrev.03/

Notes:

1. <jbs> - https://bugs.openjdk.java.net/browse/JDK-8159035 - (com/sun/crypto/provider/Cipher/CTS/CTSMode.java test crashed due to unhandled case of cipher length value as 0)
Related issues - 
    https://bugs.openjdk.java.net/browse/JDK-8076112 - 'Add @HotSpotIntrinsicCandidate annotation to indicate methods for which Java Runtime has intrinsics'
    https://bugs.openjdk.java.net/browse/JDK-8167595 - 'AArch64: SEGV in stub code cipherBlockChaining_decryptAESCrypt'

2. Found root cause of the reported jvm crash for sparc -
Crash happens at 'generate_cipherBlockChaining_decryptAESCrypt_Parallel()' [stubGenerator_sparc.cpp]
The implDecrypt can be called from CipherBlockChaining.decrypt, even with cipherLen as 0.
But the same condition is not handled in the stub code and results in crash.
(the same applicable for implEncrypt)

3. Though the reported case was for sparc, understood that same issue is present for x86, aarch64 (JDK-8167595).
So in above <webrev> fix proposed in Java wrapper method side [CipherBlockChaining.java].

4. The same issue in aarch64 (JDK-8167595) was fixed earlier in stubGenerator_aarch64.
So once above <webrev> is approved, I will initiate new hotspot webrev to revert  this earlier 8167595 change.

5. Checked for any other similar cases with HotSpotIntrinsicCandidate support and found two cases as proposed in <webrev> 
 - implCrypt() / CounterMode.java 
 - implEncodeISOArray() / ISO_8859_1.java 

Confirmed no Issues for <webrev> with  jprt testing (-testset hotspot, core)


Thanks,
Rahul