On Thu, 29 Oct 2020 17:14:17 GMT, Xue-Lei Andrew Fan <xue...@openjdk.org> wrote:
>> 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. >> >> I suggest to restore the original behavior that initializes with an >> initialCapacity of 1 in most cases. That was true when before JDK-8210985, >> the property javax.net.ssl.sessionCacheSize was not set at all. >> In case it was set, the initial size would have been like now, >> (javax.net.ssl.sessionCacheSize / 0.75f) + 1, which still seems strange. > > No regression test. > > Benchmarking is probably hard because we don't know the average occupancy > > of the map. > > I agreed. No matter what the default value is, it will not fit perfectly in > all situations. The value 1 may be fit for small workload applications, but > not good for big workload applications. Applications could use the size > setting APIs for the tuning. For this update, I think the impact for various > workload may be limited/acceptable, but I'm not very sure of it. Benchmarking > data with various workload would help us for a better sense. But we did run with `1` for quite a long time without somebody complaining :) ------------- PR: https://git.openjdk.java.net/jdk/pull/937
