RFR: 8285398: Cache the results of constraint checks

[Peter Firmstone]

Nice.

On 22/04/2022 6:47 am, Daniel Jeliński wrote:
> 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

-- 
Regards,
  
Peter Firmstone
0498 286 363
Zeus Project Services Pty Ltd.