On Thu, 21 Apr 2022 19:58:39 GMT, Daniel Jeliński <djelin...@openjdk.org> 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));
-------------
PR: https://git.openjdk.java.net/jdk/pull/8349
