Improve SSL session cache performance and scalability

A DESCRIPTION OF THE PROBLEM :
Background:
we observed that some of our servers were slow to respond, even though there were sufficient available hardware resources. Thread dump taken during such event pointed to multiple threads blocked on MemoryCache.put, with a single thread executing expungeExpiredEntries:
   java.lang.Thread.State: RUNNABLE
at sun.security.util.MemoryCache.expungeExpiredEntries(java.base@11.0.8/Unknown Source)
at sun.security.util.MemoryCache.put(java.base@11.0.8/Unknown Source)
- locked <0x000000040ce43068> (a sun.security.util.MemoryCache)
at sun.security.ssl.SSLSessionContextImpl.put(java.base@11.0.8/Unknown Source)

Analysis:
When the cache is full of recent (non-expired) entries, expungeExpiredEntries is called on every put. This operation does a full scan of the cache, linear in the size of the cache.
That scan can be easily avoided by setting either infinite capacity or infinite session timeout; both make the put operation constant-time again. However, infinite capacity quickly leads to JDK-8210985, and infinite timeout is not in line with security best practices, so a different solution is needed.

Enhancement request:
Make the put operation constant-time (or amortized constant) in cache size even when both max size and lifetime limits are set.

Data:
JMH benchmark of MemoryCache.put run on current git master (jdk 17) gives the following result on my machine:

Benchmark (size) (timeout) Mode Cnt Score Error Units
CacheBench.put 20480 86400 avgt 25 83.653 ? 6.269 us/op
CacheBench.put 20480 0 avgt 25 0.107 ? 0.001 us/op
CacheBench.put 204800 86400 avgt 25 2057.781 ? 35.942 us/op
CacheBench.put 204800 0 avgt 25 0.108 ? 0.001 us/op

Other reports:
Session cache performance problems were also reported in JDK-8202086 and JDK-8253116, but none of them points to this particular issue.