On Mon, 15 Jul 2024 08:07:21 GMT, Rajan Halade <rhal...@openjdk.org> wrote:
>> The manual test Cipher/DES/PerformanceTest.java fails with >> ArithmeticException due to potential division by zero. The issue arises when >> calculating the elapsed time using end - start, which could result in zero >> milliseconds if start and end are identical due to the high speed of >> execution. This leads to a division error in the following code snippet: >> >> >> start = System.currentTimeMillis(); >> end = System.currentTimeMillis(); >> int speed = (int)((data.length * count)/(end - start)); >> >> This issue is easily reproducible on platforms where >> System.currentTimeMillis() has low precision, such as many versions of >> Windows, end and start can be equal when obtaining >> System.currentTimeMillis() if the test runs very quickly. >> >> The fix is to provide a default value in case _end_ is not higher than >> _start_. > > test/jdk/com/sun/crypto/provider/Cipher/DES/PerformanceTest.java line 186: > >> 184: end = System.currentTimeMillis(); >> 185: >> 186: // To avoid diving by zero if end is equal to start > > Test is performing 100 and 1000 rounds of `update`. I don't think we are > seeing same start and end. Please test further to determine root cause. Could > be the case of overflow if `update` is taking long time. The root cause is that start and end are equal, leading to the exception ArithmeticException: / by zero. These rounds can execute very quickly; on a macOS platform, they can take as little as 1 millisecond. This issue is easily reproducible on platforms where System.currentTimeMillis() has low precision, such as many versions of Windows, end and start can be equal when obtaining System.currentTimeMillis() if the rounds run very quickly. (just updated the PR description including this information) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20135#discussion_r1677557655
