RFR: 8345954: Revisit Class Initializers and Locking in X509TrustManagerImpl [v3]

Artur Barashev abarashev at openjdk.org
Fri Jan 30 01:13:34 UTC 2026


On Thu, 29 Jan 2026 22:48:23 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

>> Refactor sun.security.provider.X509Factory cache access to avoid coarse-grained locking and reduce contention during certificate/CRL interning and parsing.
>> 
>> As per request in [the PR](https://github.com/openjdk/jdk/pull/22616#issuecomment-2524971845), re-visit "the initialisation and locking in this area, e.g. addToCache is a static synchronized method so very coarse locking."
>
> Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8345954: Removing synchronization on getfromcache

Not sure about this change: we used to synchronize static methods and now we synchronize static caches with pretty much the same coarse class-level locking. We should consider removing any synchronization from this class because we don't remove or modify any values from those caches, we only insert values. So even if there is a race condition then we'll just insert the same value twice. Would it be possible to insert 2 different values for the same key in this class? It doesn't seem so. FYI: those caches already synchronized internally for `get` and `put` operations.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29181#issuecomment-3821231819


More information about the security-dev mailing list