RFR: 8283681: Improve ZonedDateTime offset handling [v3]

Naoto Sato naoto at openjdk.java.net
Fri Mar 25 17:32:44 UTC 2022


On Fri, 25 Mar 2022 15:16:42 GMT, Claes Redestad <redestad at 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).
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Override ZoneOffset::normalized, cache ZoneOffset::getRules, revert change to add 2nd parameter to ZoneId::getOffset

Marked as reviewed by naoto (Reviewer).

test/micro/org/openjdk/bench/java/time/GetYearBench.java line 66:

> 64:     private TimeZone UTC = TimeZone.getTimeZone("UTC");
> 65: 
> 66:     private TimeZone LONDON = TimeZone.getTimeZone("Europe/London");

Nit: No need to use `TimeZone.getTimeZone()` here (and later convert them to `toZoneId()`). `ZoneId.of()` should suffice.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7957


More information about the core-libs-dev mailing list