RFR: 8372526: Add support for ZLIB TLS Certificate Compression [v17]

[Xuelei Fan]

Make sense to me.  Thank you!  I have no more comments.

On Wed, Feb 4, 2026 at 6:17 PM Artur Barashev <abarashev at openjdk.org> wrote:

> On Wed, 4 Feb 2026 23:33:44 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org>
> wrote:
>
> >> Artur Barashev has updated the pull request incrementally with one
> additional commit since the last revision:
> >>
> >>   Correct message name in javadoc
> >
> > src/java.base/share/classes/sun/security/ssl/SSLContextImpl.java line
> 236:
> >
> >> 234:         return compCertCache;
> >> 235:     }
> >> 236:
> >
> > Thank you for the update, @artur-oracle!   As sslContext instance are
> normally run in multiple threads context, could cache operation
> synchronization be a concern?
>
> I considered synchronization but I don't think it's really needed, the
> situation is the same as with cache being static actually:
>
> - `SoftMemoryCache` being used is already synchronized internally for
> `get` and `put` operations.
> -  Race condition is possible in between `get` and `put` operations in
> `CompressedCertProducer`, but the worst that can happen is that we either
> compress certMsg that is cached already, or insert the same compressed
> certMsg into cache twice. Not something worth to synchronize for IMO.
> - I chose `SoftMemoryCache` over `ConcurrentHashMap` because of LRU and
> soft reference mechanisms. Otherwise the former provides better per-bucket
> synchronization and atomic `computeIfAbsent` call.
>
> -------------
>
> PR Review Comment:
> https://git.openjdk.org/jdk/pull/28682#discussion_r2766747778
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20260204/60309fe9/attachment.htm>