JDK-8130289 : SecurityManager being mutable impedes the optimization of Class.getClassLoader
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.lang
  • Priority: P4
  • Status: Resolved
  • Resolution: Duplicate
  • Submitted: 2015-07-01
  • Updated: 2017-11-09
  • Resolved: 2017-11-09
Related Reports
Duplicate :  
JDK-8191053 - Provide a mechanism to make system's security manager immutable
Relates :  
JDK-6642881 - Improve performance of Class.getClassLoader()
Description
Class.getClassLoader() can't be trivially intrinsified because of the SecurityManager.

This issue is to track the idea that Christian Thalinger has (see JDK-6642881) to replace the System.security field with a VolatileCallSite.  Combined with intrinsification of Class.getClassLoader() (or better moving the class loader field up into Java) we could constant fold two security related checks. 

Attachd patch [1] is not working properly yet because of bootstrapping issues but the idea is that CallSite optimizations in the JIT compilers can constant fold the System.getSecurityManager() call. 

[1] https://bugs.openjdk.java.net/secure/attachment/18729/system-getsecuritymanager.patch
Comments
A better approach is proposed and so close this as a dup of JDK-8191053.
09-11-2017
I guess I could fabricate one but I don't have one, no. In theory if the JVM is run without a security manager and the check can be folded by the compiler performance for methods that do have a security manager check should perform better.
25-10-2017
[~twisti] can you please provide a benchmark that shows this patch improve the peak performance as you expected? Startup performance is also critical and the startup regression has to be justified.
23-10-2017
I'm sure there is a startup overhead but the motivation for this optimization is not to improve startup performance but peak performance.
23-10-2017
I have prototyped the use of VolatileCallSite: http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8130289/webrev.00/ This initializes the VolatileCallSite before the module system initialization (it should be separated from initPhase2 but this version temporarily does it for performance measurement purpose). The thought behind is that after the compiler starts up, VolatileCallSite with null target can help JIT to optimize the code (that may help the module system initialization). However the first time constructing VolatileCallSite object starts java.lang.invoke and java.lang.ref.Cleaner machinery that causes 58 additional classes to be loaded. This startup overhead impacts all applications and does not seem to give a big enough gain to offset the startup cost.
17-10-2017
Btw. JDK-6642881 moved the class loader field into Java so implementing this Enhancement would be much easier now.
10-05-2017