JDK-7092821 : java.security.Provider.getService() is synchronized and became scalability bottleneck
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.
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).
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.
It is in code review, expected to be pushed before 12 RDP: http://mail.openjdk.java.net/pipermail/security-dev/2018-December/018896.html
Is there any update? It seems the issue is stuck "In Progress" for a while now, and it is past its "Due Date"
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.
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.
attached webrev which contains suggested fix.