JDK-8255603 : Memory/Performance regression after JDK-8210985
  • Type: Bug
  • Component: security-libs
  • Sub-Component: javax.net.ssl
  • Affected Version: 11.0.5,15,16
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2020-10-29
  • Updated: 2021-04-12
  • Resolved: 2020-11-01
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11 JDK 13 JDK 15 JDK 16 JDK 8 Other
11.0.10-oracleFixed 13.0.6Fixed 15.0.2Fixed 16 b23Fixed 8u281Fixed openjdk8u282Fixed
Related Reports
Relates :  
Relates :  
Relates :  
It seems that there exists a memory/performance regression that was introduced with JDK-8210985: Update the default SSL session cache size to 20480.

The idea to limit the maixmum SSL session cache size by itself is good. Unfortunately, as per the current implementation of sun.security.util.MemoryCache, it also modifies the initial size of the LinkedHashMap that is backing the cache to initialize with more than the maximum size.
Fix request (13u) Request to backport it to 13u. The patch applies cleanly.

Fix request (8u) Request backport, as the problem is present in OpenJDK 8u since 8u222. Patch applies cleanly.

The comment block for cache details probably deserved an update during this bug fix: https://github.com/openjdk/jdk/blob/64feeab70af61a52ffe4c64df87a33c16754de18/src/java.base/share/classes/sun/security/util/Cache.java#L60-L68

Fix request (11u, 15u) Requesting backport of this regression fix to JDK11 and 15 updates. Patch applies cleanly.

Changeset: 64feeab7 Author: Christoph Langer <clanger@openjdk.org> Date: 2020-11-01 23:24:47 +0000 URL: https://github.com/openjdk/jdk/commit/64feeab7

It is a duplicate but it was opened against jdk8 so we might keep it open until this issue is fixed and downported.

Maybe JDK-8253116 is a duplicate