On Thu, 29 Oct 2020 17:06:11 GMT, Volker Simonis <simo...@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. > > Marked as reviewed by simonis (Reviewer). > 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. ------------- PR: https://git.openjdk.java.net/jdk/pull/937
