On Mon, 25 Apr 2022 13:22:34 GMT, Daniel Fuchs <dfu...@openjdk.org> wrote:
>> Right, soft references are likely to be cleaned if they are not used in an >> entire GC cycle. >> Using a soft reference for each map entry would not help here; note that all >> keys and all values in this map are GC roots (keys are enum names, values >> are `TRUE` and `FALSE`), so in practice they would never be collected. >> Even if we made the entries collectable, it would not help with the TLS >> case; SSLEngine & SSLSocket only check the constraints once at the beginning >> of the handshake, so they would all expire at the same time anyway. What's >> even worse, we would then have to clear the expired entries from the map. >> >> I also considered limiting the size of the map. That's a tricky subject; we >> would need to get the size limit exactly right. Given that the algorithms >> are always checked in the same order, if the cache were too small, we would >> get zero hits. >> With all the above in mind I decided not to use `sun.security.util.Cache` >> here. > > FWIW: I wouldn't expect `SoftReference` (as opposed to `WeakReference`) to be > eagerly cleaned. `SoftReference`s are guaranteed to survive one GC after use; beyond that their lifespan is determined by `SoftRefLRUPolicyMSPerMB` and the amount of memory available. ------------- PR: https://git.openjdk.java.net/jdk/pull/8349
