RFR: JDK-8255603: Memory/Performance regression after JDK-8210985

[Volker Simonis]

On Thu, 29 Oct 2020 17:14:17 GMT, Xue-Lei Andrew Fan <xuelei at 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