On Mon, 10 Oct 2022 16:46:25 GMT, Mark Powers <mpow...@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
