RFR: 8285398: Cache the results of constraint checks
Daniel Jeliński
djelinski at openjdk.java.net
Fri Apr 22 06:36:27 UTC 2022
On Fri, 22 Apr 2022 02:13:14 GMT, David Schlosnagle <duke at openjdk.java.net> wrote:
>> Profiling the TLS handshakes using SSLHandshake benchmark shows that a large portion of time is spent in HandshakeContext initialization, specifically in DisabledAlgorithmConstraints class.
>>
>> There are only a few instances of that class, and they are immutable. Caching the results should be a low-risk operation.
>>
>> The cache is implemented as a softly reachable ConcurrentHashMap; this way it can be removed from memory after a period of inactivity. Under normal circumstances the cache holds no more than 100 algorithms.
>
> src/java.base/share/classes/sun/security/util/DisabledAlgorithmConstraints.java line 969:
>
>> 967: result = checkAlgorithm(disabledAlgorithms, algorithm, decomposer);
>> 968: cache.put(algorithm, result);
>> 969: return result;
>
> Would it be worth using `cache.computeIfAbsent` or do you want to avoid lambda allocation overhead and potentially blocking concurrent handshakes on writer thread?
>
> Suggestion:
>
> return cache.computeIfAbsent(algorithm, algo -> checkAlgorithm(disabledAlgorithms, algo, decomposer));
I generally prefer using `get` over `computeIfAbsent` when optimizing for performance. While `computeIfAbsent` is more concise, it's also much slower than `get` when the entry is already present.
-------------
PR: https://git.openjdk.java.net/jdk/pull/8349
More information about the security-dev
mailing list