-
Enhancement
-
Resolution: Duplicate
-
P4
-
None
-
11
-
generic
-
generic
ADDITIONAL SYSTEM INFORMATION :
openjdk version "11.0.14.1"
A DESCRIPTION OF THE PROBLEM :
Hello, I am seeing heavy lock contention in SSL handshake process, via javax.crypto.Mac.getInstance. The actual synchronized method where the contention originates is sun.security.jca.ProviderConfig.getProvider. Please see partial stack trace below:
sun.security.jca.ProviderConfig
sun.security.jca.ProviderConfig.getProvider
sun.security.jca.ProviderList.getProvider
sun.security.jca.ProviderList$ServiceList.tryGet
sun.security.jca.ProviderList$ServiceList$1.hasNext
javax.crypto.Mac.getInstance
sun.security.ssl.JsseJce.getMac
sun.security.ssl.HKDF.<init>
sun.security.ssl.SSLTrafficKeyDerivation$T13TrafficKeyDerivation.deriveKey
Similar stack traces are seen for java.security.KeyFactory.getInstance, java.security.MessageDigest.getInstance and java.security.Signature.getInstance.
I noticed this bug fix seems to make the ProviderConfig.getProvider not synchronized anymore, which should help: https://bugs.openjdk.org/browse/JDK-8259065. However it is only there for Java 17, and also I am not sure if it fixes the other code paths other than for java.security.MessageDigest.getInstance.
Would it be possible to have this fix backported for Java 11 (and also to check the other code paths, such as for javax.crypto.Mac.getInstance, etc) please?
Thanks!
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1) Install Java web server that uses SSL connections
2) Issue many concurrent requests to the web server
3) Observe the lock contention with a profiler
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Minimal lock contention
ACTUAL -
Performance throughput impacted by lock contention
openjdk version "11.0.14.1"
A DESCRIPTION OF THE PROBLEM :
Hello, I am seeing heavy lock contention in SSL handshake process, via javax.crypto.Mac.getInstance. The actual synchronized method where the contention originates is sun.security.jca.ProviderConfig.getProvider. Please see partial stack trace below:
sun.security.jca.ProviderConfig
sun.security.jca.ProviderConfig.getProvider
sun.security.jca.ProviderList.getProvider
sun.security.jca.ProviderList$ServiceList.tryGet
sun.security.jca.ProviderList$ServiceList$1.hasNext
javax.crypto.Mac.getInstance
sun.security.ssl.JsseJce.getMac
sun.security.ssl.HKDF.<init>
sun.security.ssl.SSLTrafficKeyDerivation$T13TrafficKeyDerivation.deriveKey
Similar stack traces are seen for java.security.KeyFactory.getInstance, java.security.MessageDigest.getInstance and java.security.Signature.getInstance.
I noticed this bug fix seems to make the ProviderConfig.getProvider not synchronized anymore, which should help: https://bugs.openjdk.org/browse/JDK-8259065. However it is only there for Java 17, and also I am not sure if it fixes the other code paths other than for java.security.MessageDigest.getInstance.
Would it be possible to have this fix backported for Java 11 (and also to check the other code paths, such as for javax.crypto.Mac.getInstance, etc) please?
Thanks!
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1) Install Java web server that uses SSL connections
2) Issue many concurrent requests to the web server
3) Observe the lock contention with a profiler
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Minimal lock contention
ACTUAL -
Performance throughput impacted by lock contention
- clones
-
JDK-8304700 Improve lock contention in javax.crypto.Mac.getInstance
-
- Open
-
- duplicates
-
JDK-8304700 Improve lock contention in javax.crypto.Mac.getInstance
-
- Open
-
- relates to
-
JDK-8259065 Optimize MessageDigest.getInstance
-
- Resolved
-