On Mon, 23 Oct 2023 17:33:48 GMT, Eamonn McManus <emcma...@openjdk.org> wrote:
> The existing logic uses nanosecond arithmetic to compute Duration.between. > Since that can overflow for durations greater than 292 years, it has a > try/catch that falls back to computing the seconds part and adjusting that > for nanoseconds. However, exception handling is typically very expensive, so > in cases like the one in the linked bug this method was a performance trap. > > The new logic is essentially the old catch block. It needs a special case for > when the number of seconds is 0, so it is slightly slower in that case. But > in other cases it is probably somewhat faster, because it avoids a > [division](https://github.com/openjdk/jdk/blob/8d9a4b43f4fff30fd217dab2c224e641cb913c18/src/java.base/share/classes/java/time/Duration.java#L283) > and associated mod. > > The test coverage in > [`TCKDuration`](https://github.com/openjdk/jdk/blob/8d9a4b43f4fff30fd217dab2c224e641cb913c18/test/jdk/java/time/tck/java/time/TCKDuration.java#L780) > is already very thorough so no new tests are needed. Yes, what I tried was just removing the catch-block from the existing code and verifying that `TCKDuration` fails with `ArithmeticException`. It calls `between` on `Instant` values that are 500 years apart, which is enough to trigger nanosecond overflow. So both the original `try` and the original `catch` are tested. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16318#issuecomment-1777777159
