JEP 232: Improve Secure Application PerformanceJEP 232: Improve Secure Application PerformanceOwnerSean MullanTypeFeatureScopeImplementationStatusClosed / DeliveredRelease9Componentsecurity-libs / java.securityDiscussionsecurity dash dev at openjdk dot java dot netEffortMDurationLReviewed byBrian GoetzEndorsed byBrian GoetzCreated2014/05/21 12:57Updated2017/03/10 16:07Issue8043631Summary
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 of java.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 of
java.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.
InstallingContributingSponsoringDevelopers' GuideVulnerabilitiesJDK GA/EA BuildsMailing listsWiki
                      · IRCBylaws · CensusLegalWorkshopJEP ProcessSource codeMercurialGitHubToolsGitjtreg harnessGroups(overview)AdoptionBuildClient LibrariesCompatibility & Specification ReviewCompilerConformanceCore LibrariesGoverning BoardHotSpotIDE Tooling & SupportInternationalizationJMXMembersNetworkingPortersQualitySecurityServiceabilityVulnerabilityWebProjects(overview,
      archive)AmberBabylonCRaCCaciocavalloClosuresCode ToolsCoinCommon VM InterfaceCompiler GrammarDetroitDevelopers' GuideDevice I/ODukeGalahadGraalIcedTeaJDK 7JDK 8JDK 8 UpdatesJDK 9JDK
      (…,
       21,
       22,
       23)JDK UpdatesJavaDoc.NextJigsawKonaKullaLambdaLanaiLeydenLilliputLocale EnhancementLoomMemory Model UpdateMetropolisMission ControlMulti-Language VMNashornNew I/OOpenJFXPanamaPenrosePort: AArch32Port: AArch64Port: BSDPort: HaikuPort: Mac OS XPort: MIPSPort: MobilePort: PowerPC/AIXPort: RISC-VPort: s390xPortolaSCTPShenandoahSkaraSumatraTiered AttributionTsanType AnnotationsValhallaVeronaVisualVMWakefieldZeroZGC

        © 2024 Oracle Corporation and/or its affiliates
        Terms of Use
        ·
        
            License: GPLv2
        · Privacy
        · Trademarks
