RFR: 8285398: Cache the results of constraint checks

David Schlosnagle duke at openjdk.java.net
Fri Apr 22 02:21:24 UTC 2022

On Thu, 21 Apr 2022 19:58:39 GMT, Daniel Jeliński <djelinski at 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?


        return cache.computeIfAbsent(algorithm, algo -> checkAlgorithm(disabledAlgorithms, algo, decomposer));


PR: https://git.openjdk.java.net/jdk/pull/8349

More information about the security-dev mailing list