RFR: 8285398: Cache the results of constraint checks
Daniel Jeliński
djelinski at openjdk.java.net
Mon Apr 25 14:03:28 UTC 2022
On Mon, 25 Apr 2022 13:22:34 GMT, Daniel Fuchs <dfuchs at 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
More information about the security-dev
mailing list