On Wed, 5 Oct 2022 05:43:32 GMT, Xue-Lei Andrew Fan <[email protected]> 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."
-------------
PR: https://git.openjdk.org/jdk/pull/10568
