<i18n dev> RFR: 8345668: ZoneOffset.ofTotalSeconds performance regression [v3]

[Naoto Sato]

On Mon, 30 Dec 2024 17:44:11 GMT, Brett Okken <duke at openjdk.org> wrote:

>> Indeed, just noticed that both `computeIfAbsent` and `putIfAbsent` may acquire the lock when the key is present, while `get` never acquires a lock for read-only access.
>> 
>> Maybe the implementation was written back when locking was less costly (with biased locking, etc.). Now we might have to reconsider locking until we know for sure a plain get fails.
>
> This scenario is discussed in Effective Java by Joshua Block. His observation then (java 5/6 time frame?) was optimistically calling `get` first and only calling `putIfAbsent` or `computeIfAbsent` if the `get` returned `null` was 250% faster, and this is because calls to put/compute ifAbsent have contention. There have been changes made to those methods since then to try to avoid synchronization when the key is already present, but the observation seems to confirm that the optimistic `get` call first is still faster (though a much smaller difference).
> 
> My comment was not to revert back to the prior change of just calling `computeIfAbsent`, but rather just to change the (expected rare) case when the first `get` returns `null` to replace the `putIfAbsent` and second `get` call with a single `computeIfAbsent` (or utilize the result of `putIfAbsent` to avoid the second call to `get`).

Thanks for your observations. I think Archie's analysis sounds right, although have not confirmed. Will use the result from `putIfAbsent()` for all cases.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22854#discussion_r1901121904