On Mon, 25 Apr 2022 06:46:20 GMT, Daniel Jeliński <djelin...@openjdk.org> wrote:
>> src/java.base/share/classes/sun/security/util/DisabledAlgorithmConstraints.java >> line 105: >> >>> 103: private final Set<String> disabledAlgorithms; >>> 104: private final Constraints algorithmConstraints; >>> 105: private volatile SoftReference<Map<String, Boolean>> cacheRef = >> >> It looks like a one-clear-for-all mechanism. Once the clearing happens, the >> full map will be collected. For SoftReferences, it clears them fairly >> eagerly. Maybe, the performance could be further improved in practice by >> using soft reference for each map entry (See sun.security.util.Cache code >> for an example). >> >> I will have another look next week. > > 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. ------------- PR: https://git.openjdk.java.net/jdk/pull/8349
