RFR: 8285398: Cache the results of constraint checks

[Daniel Jeliński]

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.

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