On Thu, 2 Feb 2023 15:44:54 GMT, Per Minborg <pminb...@openjdk.org> wrote:
>> `ZoneOffset` instances are cached by the `ZoneOffset` class itself for >> values in the range [-18h, 18h] for each second that is on an even quarter >> of an hour (i.e. at most 2*18*4+1 = 145 values). >> >> Instead of using a `ConcurrentHashMap` for caching instanced, we could >> instead use an `AtomicReferenceArray` with direct slot value access for said >> even seconds. This will improve performance and reduce the number of object >> even though the backing array will go from an initial 32 in the CHM to an >> initial/final 145 in the ARA. The CHM will contain much more objects and >> array slots for typical numbers of entries in the cache and will compute >> hash/bucket/collision on the hot code path for each cache access. > > Per Minborg has updated the pull request incrementally with one additional > commit since the last revision: > > Fix benchmark Updated figures with the new benchmark: Baseline Result "org.openjdk.bench.java.time.ZoneOffsetBench.getFromCache": 887.478 ±(99.9%) 10.206 ns/op [Average] (min, avg, max) = (876.206, 887.478, 906.754), stdev = 9.547 CI (99.9%): [877.271, 897.684] (assumes normal distribution) Patch Result "org.openjdk.bench.java.time.ZoneOffsetBench.getFromCache": 252.646 ±(99.9%) 2.794 ns/op [Average] (min, avg, max) = (250.451, 252.646, 258.890), stdev = 2.614 CI (99.9%): [249.851, 255.440] (assumes normal distribution) JDK 20 - Baseline (JDK 21 before patch) JDK 21 - Patch  ------------- PR: https://git.openjdk.org/jdk/pull/12346
