RFR: 8283681: Improve ZonedDateTime offset handling [v2]
Stephen Colebourne
scolebourne at openjdk.java.net
Fri Mar 25 15:20:45 UTC 2022
On Fri, 25 Mar 2022 14:35:46 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:
>
> Add nanoOfSecond parameter, make micro less reliant on constants
src/java.base/share/classes/java/time/ZoneOffset.java line 512:
> 510: @Override
> 511: /* package-private */ ZoneOffset getOffset(long epochSecond, int nanoOfSecond) {
> 512: return this;
An alternate approach would be for `ZoneOffset` to cache the instance of `ZoneRules` either on construction or first use (racy idiom would be OK). That way this issue is solved for the many different places that call `zoneId.getRules()`.
-------------
PR: https://git.openjdk.java.net/jdk/pull/7957
More information about the core-libs-dev
mailing list