On Wed, 5 Oct 2022 05:43:32 GMT, Xue-Lei Andrew Fan <xue...@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 I wonder if it would be worthwhile to have a static method that could be called in an assert (or in a test using --patch-module) to verify that the various statically initialized arrays are the same than those that would have been computed by the old code? ------------- PR: https://git.openjdk.org/jdk/pull/10568
