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. before: Benchmark (resume) (tlsVersion) Mode Cnt Score Error Units SSLHandshake.doHandshake true TLSv1.2 thrpt 5 2165.081 ± 440.204 ops/s SSLHandshake.doHandshake true TLS thrpt 5 534.681 ± 146.931 ops/s SSLHandshake.doHandshake false TLSv1.2 thrpt 5 369.104 ± 11.143 ops/s SSLHandshake.doHandshake false TLS thrpt 5 253.903 ± 58.056 ops/s after: Benchmark (resume) (tlsVersion) Mode Cnt Score Error Units SSLHandshake.doHandshake true TLSv1.2 thrpt 5 10440.501 ± 478.177 ops/s SSLHandshake.doHandshake true TLS thrpt 5 762.995 ± 33.842 ops/s SSLHandshake.doHandshake false TLSv1.2 thrpt 5 440.471 ± 52.867 ops/s SSLHandshake.doHandshake false TLS thrpt 5 305.928 ± 57.847 ops/s After this patch the HandshakeContext initialization practically disappears from the CPU profile; it only takes ~5% in TLS1.2 resumption, and much less in the remaining scenarios. ------------- PR: https://git.openjdk.java.net/jdk/pull/8349