<i18n dev> RFR: 8288723: Avoid redundant ConcurrentHashMap.get call in java.time

[liach]

On Tue, 21 Jun 2022 09:35:34 GMT, Attila Szegedi <attila at openjdk.org> wrote:

>> This behaves slightly different from the old initialization; the concurrent hash map blocks when the mapping function is run, just in case if non-blocking instantiation is what we want. If that's not a problem, I would prefer szegedi's suggestion.
>
> @liach advance apologies for nitpicking: `ConcurrentHashMap` doesn't in general block while the mapping function runs. It can block _some_ concurrent updates, namely those that [hash to the same bin](https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/0f801fe6fd2fcc181121f9846f6869ca3a03e18a/src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java*L324__;Iw!!ACWV5N9M2RV99hQ!M4ZprjzcHmsRVcqNAOpWURcdiarGLRrv7X38D3a9Htm65FjMP7qzt8n8xS2ZS7FmPHKJ7qflZ0cOiqsTGQ$ ) and it won't block concurrent reads. I'm not saying the concern you raised isn't valid, just wanted to clarify that the situation is not nearly as grave as overall blocking; after all it ain't a `Collections.synchronizedMap` :-)

Yeah, since `putIfAbsent` may block `get` calls, the blocking of `computeIfAbsent` is minuscule as long as the creation code is efficient enough. Just be careful that when writing the lambda for `computeIfAbsent`, preferably write static lambdas (that doesn't use `this`, instances, or local variables) so that one lambda can be reused over time than having to create a new one on each invocation.

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

PR: https://git.openjdk.org/jdk/pull/9208