RFR: 8294821: Class load improvement for AES crypto engine

[Xue-Lei Andrew Fan]

On Mon, 10 Oct 2022 16:46:25 GMT, Mark Powers <mpowers at openjdk.org> wrote:

>> Hi,
>> 
>> May I have the code clean up reviewed?
>>  
>> There is a lot of computation in AESCrypt class load, which could be avoid by using the computation result directly. The computation takes 6.971875 milliseconds in a MacOS M1 laptop. Although it is a one-time computation, but removing the computation could speed up java/jvm loading time by 6.971875 milliseconds without extra memory cost. 
>> 
>> Actually, because the computation result are used directly, the methods that supports the computation are no longer needed and the related static arrays are no longer needed.  This is the extra benefits to use the computation result directly, rather than computing on class initialization.
>> 
>> This patch does not change the logic except removing the pre-computation code and initializing the tables with the pre-computed result explicitly.  The existing regression and inter-op tests should be sufficient to ensure that the tables are correctly copied from the dumping of the old computation code results.
>> 
>> Except that, I also cleaned up some code warnings from the IDE I used.
>> 
>> Thanks,
>> Xuelei
>
> src/java.base/share/classes/com/sun/crypto/provider/AESCrypt.java line 1065:
> 
>> 1063:      * @param decrypting True if 'kr' is for decryption and false otherwise.
>> 1064:      */
>> 1065:     private static int[] expandToSubKey(int[][] kr, boolean decrypting) {
> 
> I received the following code review comment back in April:
> "Even though a static method is implicitly final and IJ is correct, the final keyword does prevent subclasses from inadvertently using the same method signature."

Good point!

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

PR: https://git.openjdk.org/jdk/pull/10568