JEP 232: Improve Secure Application Performance
Owner | Sean Mullan |
Type | Feature |
Scope | Implementation |
Status | Closed / Delivered |
Release | 9 |
Component | security-libs / java.security |
Discussion | security dash dev at openjdk dot java dot net |
Effort | M |
Duration | L |
Reviewed by | Brian Goetz |
Endorsed by | Brian Goetz |
Created | 2014/05/21 12:57 |
Updated | 2017/03/10 16:07 |
Issue | 8043631 |
Summary
Improve the performance of applications that are run with a security manager installed.
Goals
Gain a better understanding of the performance issues and implement enhancements that are demonstrated to improve performance. Subtasks will be created to evaluate and track each potential improvement.
Non-Goals
Improving performance is a desirable outcome, but this JEP will not commit to any specific metrics by which performance will improve.
Motivation
Improving the performance of applications run with a security manager has been requested by many developers using Java SE, Java EE, and related technologies. Although specific numbers are not confirmed and can vary depending on several factors, running a Java application with a security manager enabled has been known to cause a 10-15% performance degradation. Although some performance penalty is unavoidable, narrowing this performance gap has both performance and security benefits.
Description
We explored and implemented a number of optimizations and enhancements for improving the performance of applications that are run with a security manager installed. Some of these optimizations improved performance, while others did not. A few others were shown to have promise, but for various reasons will not be integrated as part of this JEP. New JBS issues were opened (if none previously existed) for each of the optimizations that were considered and micro-benchmarks were created using JMH.
Optimizations
Based on testing and community feedback, our primary focus area for improving performance was the enforcement of security policy and the evaluation of permissions. The permission classes and default JDK policy implementation are designed to be thread-safe. However, performance tests with multiple threads show that these classes are a hot spot. We implemented several improvements that improve throughput and reduce thread contention:
- Use ConcurrentHashMap to map ProtectionDomain to PermissionCollection
- SecureClassLoader should use a ConcurrentHashMap
- Remove Policy provider code that synchronizes on identityPolicyEntries List
- Store PermissionCollection entries in a ConcurrentHashMap instead of a HashMap in Permissions class
- Store permissions in concurrent collections in PermissionCollection subclasses
We also improved performance in two other key areas:
-
We changed the
hashCode
method ofjava.security.CodeSource
to avoid potentially expensive DNS lookups by using a string form of the codesource URL to compute the hash code. See JDK-6826789 for more information. -
We enhanced the package checking algorithm of the
checkPackageAccess
method ofjava.lang.SecurityManager
. See JDK-8072692 for more information.
Testing
Tests will be needed to measure performance before and after each potential optimization is applied. More than one test may need to be implemented to ensure proper code coverage, and to reflect different types of use cases. Profiling tools will be used to help identify areas of potential optimization. In addition, we will run the SPECjEnterprise benchmark to measure the performance impact of the optimizations on Java EE applications.
Finally, each optimization will be measured across all supported JDK platforms in order to ensure that the results are consistently positive.