On Fri, 25 Mar 2022 12:28:58 GMT, Claes Redestad <redes...@openjdk.org> wrote:
> Richard Startin prompted me to have a look at a case where java.time > underperforms relative to joda time > (https://twitter.com/richardstartin/status/1506975932271190017). > > It seems the java.time test of his suffer from heavy allocations due > ZoneOffset::getRules allocating a new ZoneRules object every time and escape > analysis failing to do the thing in his test. The patch here adds a simple > specialization so that when creating ZonedDateTimes using a ZoneOffset we > don't query the rules at all. This removes the risk of extra allocations and > slightly speeds up ZonedDateTime creation for both ZoneOffset (+14%) and > ZoneRegion (+5%) even when EA works like it should (the case in the here > provided microbenchmark). src/java.base/share/classes/java/time/ZoneRegion.java line 183: > 181: @Override > 182: /* package-private */ ZoneOffset getOffset(long epochSecond) { > 183: return getRules().getOffset(Instant.ofEpochSecond(epochSecond)); The nanoAdjustment passed to `ofEpochSecond` is discarded in this code. It may be larger than a second; see `Instant.ofEpochSecond(sec, nano)` for the details. Adding a second parameter to the `getOffset` method could be the remedy. ------------- PR: https://git.openjdk.java.net/jdk/pull/7957
