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

Artur Barashev abarashev at openjdk.org
Fri Jan 30 13:43:55 UTC 2026


On Fri, 30 Jan 2026 05:46:32 GMT, Koushik Muthukrishnan Thirupattur <duke at openjdk.org> wrote:

> > 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.
> 
> Thanks for the detailed comment. You’re right that this won’t corrupt the cache and that the objects are semantically equivalent. The issue I see isn’t correctness of the cache, but interning/canonicalization semantics.
> 
> I think it could be possible for two values to be inserted for the same logical key: if two threads concurrently miss on `get()`, they can both construct separate `X509CertImpl/X509CRLImpl` instances and then both call `put()`. The cache remains valid, but different callers may observe different object instances for the same certificate/CRL. That breaks the intent of `intern()` as documented (returning a canonical cached instance) and can introduce avoidable object churn.
> 
> The addIfNotPresent() helper keeps the “check-then-insert and return existing” behavior atomic at this layer, without relying on assumptions about the cache implementation. I would be happy to revisit if we agree interning semantics are not required here. Let me know.

I see your point, but since this is `SoftMemoryCache` there is no guarantee it will always return the same exact object for the same key anyhow. The callers of `intern` method can't rely on that. SoftReferences are automatically cleared by the garbage collector in response to memory demand, then the new object will be re-inserted.

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

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


More information about the security-dev mailing list