JDK-8065942 : Store PermissionCollection entries in a ConcurrentHashMap instead of a HashMap in Permissions class
  • Type: Enhancement
  • Component: security-libs
  • Sub-Component: java.security
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2014-11-25
  • Updated: 2015-06-23
  • Resolved: 2015-06-09
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 9
9 b69Fixed
Related Reports
Relates :  
JDK-8062948 - Implement and measure potential performance improvements
Relates :  
JDK-8129575 - Equal DelegationPermission instances may return different hash codes
Description
Currently, the code has several synchronized blocks around get/put operations to the HashMap. The policy provider caches a Permissions object per ProtectionDomain, so this can easily become a thread contention point when multiple threads are checking permissions.

My benchmark with 8 threads which tests the performance of implies against a Permissions object containing a collection of different Permission objects shows about a 2x throughput improvement of Permissions.implies after I made this change. Prior to my change, a profiler showed that Permissions.implies was blocked 72% of the time. Afterwards, 0 %.
Comments
Attached is a chart comparing the performance of Permissions.getPermissions(Permission) before and after the fix with various numbers of threads. The system under test was Intel�� Core��� i5-2520M CPU @ 2.50GHz �� 4 running Ubuntu 14.04 LTS. Single thread performance is better (by about 9%) and multiple-thread throughput is increased 2-4 times depending on the number of threads.
28-05-2015
Throughput performance improvement of benchmark is roughly as follows (4 CPU system): 1 thread : 8% 8 threads : 89%
02-12-2014
The next point of thread contention to work on after this fix will be the various subclasses of Permission that implement their own PermissionCollections. These all show that threads are blocked on the implies method of the PermissionCollection subclasses implemented by these classes. The fix for this issue causes one new regression: test/java/security/PermissionCollection/Concurrent.java now fails with a ConcurrentModificationException, which is thrown by one of the PermissionCollection subclasses of the Permission subclasses. However, this is not really a regression. Removing the synchronization in Permissions has exposed an underlying bug in these Permission subclasses, in that the PermissionCollection.elements method is not supposed to be fail-fast (see the end of the PermissionCollection class summary for more info). It should not throw ConcurrentModificationException.
02-12-2014