RFR: 8345954: Revisit Class Initializers and Locking in X509TrustManagerImpl [v3]
Artur Barashev
abarashev at openjdk.org
Tue Feb 3 13:57:13 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
While option 2 is more likely, I suggest to explore both options. The important thing with option 2 is to make sure we don't compare certificate or CRLs with `==` operator anywhere in OpenJDK code (so far I've only done a quick research on this). Then we can remove synchronization around `certCache` and `crlCache` completely and update `intern` methods javadoc (or maybe rename those methods to avoid any confusion).
Those are static caches shared across the whole VM, so we want to make sure the locking is reduced to the bare minimum, especially since it's been documented to be an issue.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/29181#issuecomment-3841469430
More information about the security-dev
mailing list