JDK-7092821 : java.security.Provider.getService() is synchronized and became scalability bottleneck
  • Type: Enhancement
  • Component: security-libs
  • Sub-Component: java.security
  • Affected Version: 7
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2011-09-20
  • Updated: 2020-08-14
  • Resolved: 2018-12-13
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11 JDK 12 JDK 13 JDK 8
11.0.7Fixed 12 b24Fixed 13Fixed 8u241Fixed
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Description
java.security.Provider.getService() is synchronized and became scalability bottleneck when Cipher.getInstance() is frequently called.

The problem is important for SPECjvm2008:crypto.rsa (+27% on SPARC when fixed) and for SPECjvm2011.

Fix is suggested (inroduce cache based on ConcurrentHashMap).

Comments
Fix request (11u) A useful performance improvement that's in use at Amazon. Applies cleanly, passes jdk/sun/security and jdk/com/sun/security tests.
28-01-2020

It is in code review, expected to be pushed before 12 RDP: http://mail.openjdk.java.net/pipermail/security-dev/2018-December/018896.html
07-12-2018

Is there any update? It seems the issue is stuck "In Progress" for a while now, and it is past its "Due Date"
07-12-2018

Instead of adding an extra cache, will alleviate the bottleneck by changing providers to register through Provider.Service model and thus look up the services through the serviceMap instead of through the legacyStrings.
13-05-2016

EVALUATION Some of the suggested changes looks somewhat redundant, e.g. is it really necessary to have another static class DoubleStringKey when there is already a ServiceKey class which encapsulates the exact same 2 variables and behaves in the same way? I think the key idea here is to use a cache to avoid the synchronization bottleneck of Provider.getService() calls. So, will make minor modification to the suggested changes.
11-01-2012

SUGGESTED FIX attached webrev which contains suggested fix.
20-09-2011